Relembrando Arrays

Um array, ou matriz, ou ainda um arranjo, é uma abstração matemática utilizada para representar um conjunto de dados homogêneos, ou seja do mesmo tipo (int, float, etc). Essa abstração é organizada em formato de tabela, com linhas e colunas. Cada elemento na matriz possui coordenadas únicas (linha e coluna), de forma que um dado elemento E(i,j) representa o único elemento na posição “linha i”, “coluna j”.

A sintaxe de declaração de matrizes segue abaixo:

// Matrizes unidimensionais ou vetores
int     ivet[10];               // 10 elementos, do 0 ao 9
char    cvet[23];               // 23 elementos, do 0 ao 22
 
// Matrizes bidimensionais
int     imat[2][3];             // 2 linhas (0 a 1) e 3 colunas (0 a 2)
double  dmat[10][2];            // 10 linhas (0 a 9) e 2 colunas (0 a 1)

Cada elemento da matriz é independente dos demais e pode ser acessado conforme a sintaxe abaixo:

int ivet[10];
int imat[3][4];
 
// Alterando o quarto elemento do vetor ivet.
// Lembre-se que começa-se a contar a partir do elemento zero
ivet[3] = 13;
 
// Lendo o segundo elemento do vetor ivet
int num = ivet[1];
 
// Alterando o elemento da primeira linha, segunda coluna de imat
imat[0][1] = 42;
 
// Lendo o elemento na terceira linha, quarta coluna de imat
int foo = imat[2][3];

Neste post não vamos discutir a fundo matrizes, vamos apenas investigar a relação entre matrizes e ponteiros de uma forma bastante intuitiva.

Tamanhos de matrizes

Dado que uma matriz é uma abstração que comporta vários valores de um mesmo tipo, qual o tamanho dela? Quanto espaço ele ocupa na memória?

Considere o código abaixo:

17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

int     ivet[10];
char    cvet[13];
double  dvet[20];
 
char    cmat[3][4];
int     imat[5][4];
 
cout << "sizeof(int)     = " << sizeof(int) << endl;
cout << "sizeof(char)    = " << sizeof(char) << endl;
cout << "sizeof(double)  = " << sizeof(double) << endl;
 
cout << "sizeof(ivet)    = " << sizeof(ivet) << endl;
cout << "sizeof(cvet)    = " << sizeof(cvet) << endl;
cout << "sizeof(dvet)    = " << sizeof(dvet) << endl;
cout << "sizeof(cmat)    = " << sizeof(cmat) << endl;
cout << "sizeof(imat)    = " << sizeof(imat) << endl;

O resultado é bastante razoável. O Espaço ocupado por uma matriz é igual ao número de elementos multiplicado pelo tamanho do tipo do elemento (linhas x colunas x sizeof(tipo)). Ora, se cada elemento é independente, supõe-se que cada um ocupe um lugar separado na memória, caso contrário um elemento sobrescreveria outro. Sendo assim, será que cada elemento possui seu próprio endereço de memória?

Matrizes e endereços de memória

Para facilitar, vamos então analisar os possíveis endereços de uma matriz de caracteres, cujo tamanho de um dado único é 1 byte:

15
16
17
18
19
20
21
22
23
24
25
26
27
28

const int max = 5;
char cvet[max] = {'A', 'B', 'C', 'D', 'E'};
 
// Mostrando o índices, valores e endereços dos dados.
printf("Índice\tValor\tEndereço do elemento\n");
for (int i = 0; i < max; i++) {
    printf("%d\t%c\t%p\n", i, cvet[i], &cvet[i]);
}
 
// Mostrando o endereço da própria matriz
printf("Endereço da matriz: %p\n", &cvet);
 
// Mostrando o endereço da própria matriz denovo
printf("Endereço da matriz: %p\n", cvet);

Os endereços dos elementos são sequenciais, ou seja, cada elemento é armazenado ao lado do anterior. Adicionalmente existem dois fatos ainda mais interessantes:

1. O endereço do array (&cvet), mostrado na linha 25, é o mesmo do primeiro elemento do array;
2. A própria variável cvet pode ser interpretada como um ponteiro, como é mostrado na linha 28;

Em C++, um array comum é um bloco contíguo de memória cujo nome pode ser interpretado (cast) como um ponteiro que aponta para o seu primeiro elemento. Adicionalmente é válido fazer um ponteiro apontar para um array desde que o ponteiro destino seja para o mesmo tipo que o tipo dos elementos do array. Durante a atrubuição de um array a um ponteiro, o compilador faz uma conversão implícita de tipos. O ponteiro destino passa a ser interpretado como um ponteiro para a área de memória ocupada pelo array.

Uma das consequências não tão óbvias é que durante o cast implícito, é perdida a informação de que aquela área de memória era um array. Portanto é perdida a informação do tamanho do array. Do ponto de vista do ponteiro, ele está apontando para o começo de um bloco arbitrário de memória, de um tamanho também arbitrário. Sair de um array e ir para um ponteiro significa ir de uma abstração mais restritiva e mais alto nível, para um abstração menos restritiva e mais baixo nível.

Por outro lado tentar atribuir um ponteiro a um array gera um erro de compilação por tipos incompatíveis. Um array é um bloco de memória de n dados (bytes), já um ponteiro possui apenas um dado, um endereço. O compilador não tem como saber de antemão se um ponteiro aponta para uma área de 1, 2 ou 200 bytes.

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

const int max = 300;
char cvet[max];
char* pc = 0;
 
printf("\nAntes da atribuição\n");
printf("cvet = %p\n", cvet);
printf("pc   = %p\n", pc);
printf("sizeof(cvet) = %lu\n", sizeof(cvet));
printf("sizeof(pc)   = %lu\n", sizeof(pc));
 
pc = cvet;
 
printf("\nDepois da atribuição\n");
printf("cvet = %p\n", cvet);
printf("pc   = %p\n", pc);
printf("sizeof(cvet) = %lu\n", sizeof(cvet));
printf("sizeof(pc)   = %lu\n", sizeof(pc));

Note que antes da atribuição (linha 25) o ponteiro pc. está nulo, pois foi inicializado assim. Já os tamanhos indicam que o array possui 300 bytes e o ponteiro apenas 8 (minha máquina é um amd 64). Após a atribuição ambos passam a “apontar” para a mesma área de memória, porém os tamanhos não mudam. Houve um cast implicito de char[300] para char*, e nessa brincadeira o ponteiro pc não tem como saber o tamanho da área de memória para o qual ele aponta. Já o array cvet continua sabendo direitinho o que ele é, sem nenhuma crise existencial.

Aritmética de ponteiros – Vulgo, e daí?

Ora, mas se eu sei que os dados numa matriz estão dispostos lado a lado, eu posso utilizar um ponteiro que vai pulando para o endereço ao lado e acessando o elemento seguinte. O nome disso é aritimética de ponteiros.

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

const int max = 6; 
char cvet[max] = {'B','L','A','B','O','S'};
 
char* pc = cvet;
 
for (int i = 0; i < max; i++) {
    printf("%c", *(pc + i));
}
printf("\n");
 
for (int i = 0; i < max; i++) {
    printf("%c", *pc++);
}
printf("\n");
 
 
// Agora com inteiros
int ivet[max] = {1, 2, 3, 4, 5, 6};
int* pi = ivet;
 
for (int i = 0; i < max; i++) {
    printf("%p = %d\n", pi, *pi++);
}
printf("\n");
 
// Em duas dimensões
char cmat[2][3] = {{'B','L','A'},{'B','O','S'}};
char* ppc;
 
ppc = (char*)cmat;
 
for (int i = 0; i < 2; i++) {
    for (int j = 0; j < 3; j++) {
        printf("%c", *(ppc + 3*i+j));
    }
    printf("\n");
}
printf("\n");

Na linha 18 o ponteiro pc passa a pontar para o array cvet, e consequentemente para o seu primeiro elemento, o caracter ‘B’. Na linha 21 o conteúdo de pc, que é o endereço onde foi armazenado o caracter ‘B’, é incrementado de i e em seguida de-referenciado. Na primeira passada o valor de i é zero, portanto é dereferenciado para o valor ‘B’. Nos passos seguintes, o endereço seguinte vai sendo de-referenciado para os outros caracteres armazenados no array original. É mais ou menos isso que internamente o compilador faz quando você utiliza a sintaxe cvet[i]. A abstração de array te dá uma forma mais amigável de tratar áreas contíguas de memória do que *(pc + i).

Mas se a abstração de array é mais simples, pra que utilizar aritmética de ponteiros?

Uma das respostas está a linha 26. Ela faz a mesma coisa que a linha 21, porém um pouco mais rápido. Na sintaxe da linha 21, ou de forma semelhante, na sintaxe de array, o acesso a um dado qualquer pode ser resumido de forma bem grosseira nos comandos:

1. Tome o endereço base do array;
2. Adicione ao endereço o valor do índice;
3. De-referencie este novo endereço;

Já com aritmética de ponteiro ficaria assim:

1. De-referencie este endereço;

O comando incremento (ou a conta feita com endereços) não vou contar porque é parte do loop, embora i++; seja mais rápido que a = b + c;. Agora imagine esse pequeno ganho de 66% aplicado em uma área de dados de 1 MB. Serão mais de 2 milhões de comandos a menos!

A técnica de utilizar um ponteiro para manipular uma área arbitrária de memória é utilizada geralmente em programação de baixo nível (mais próximo da máquina), manipulação de buffers e strings, entre outros truques sujos. Nas entranhas dos computadores, operações que varrem extensas áreas de memória, frequentemente são realizadas com aritimética de ponteiros. Nesse nível, Darwin reina supremo e só os mais preparados sobrevivem. A partir daqui a linguagem começa a dar um poder que só os puros de coração conseguem compreender.

Uma observação importante é que entre as linhas 31 e 38 a experiência é repetida com inteiros. Note que como os inteiros possuem 4 bytes, os incrementos são automaticamente feitos de 4 em 4 bytes, e não de 1 em 1, ou seja o incremento é automaticamente calculado para sizeof(tipo). Incrementar um ponteiro significa acessar a próxima área de memória semelhante ao dado atual, e não apenas o próximo endereço. Como o tamanho de um char é um byte, quando incremetamos um ponteiro para char, avançamos apenas 1 byte. Se incrementarmos um ponteiro para double, avançaremos 8 bytes, e assim por diante.

Outra observação é que uma matriz bidimensional pode ser “linearizada” conforme é mostrado nas linhas 40 a 52. Isso é útil, quando aplicável, para aproveitar melhor o cache do processador, por exemplo.

void*, o Pansexual dos ponteiros

Anteriormente eu disse que só era possível atribuir um array a um ponteiro que fosse para o mesmo tipo que os dados do array. Eu menti descaramente! O motivo, é que para alguém que desistiu do post antes deste tópico, é mais seguro acreditar que não pode !

Existem duas exceções à regra. A primeira é quando há uma conversão explícita de tipos e o ponteiro destino “acha” que está apontando para o tipo certo. Um exemplo está na linha 44 do código anterior.

A segunda é o caso dos ponteiros para void. Um ponteiro para void é um ponteiro que não faz exigências quanto ao tipo de dados que está na área de memória para o qual ele aponta. Ele é um ponteiro pra uma área genérica de memória, algo bem baixo nível.

Para utilizar um dado apontado por um ponteiro para void, antes de de-referenciá-lo, é preciso fazer um cast explícito para algum tipo válido, pois se um int* é de-referenciado para int e um char* é de-referenciado para char, adivinhe para que é de-referenciado um void*?

15
16
17
18
19
20
21
22
23
24
25
26
27

const int max = 6; 
char cvet[max] = {'B','L','A','B','O','S'};
 
void* pv = cvet;
 
// Erro de compilação.
//*pv
// Quanto vale sizeof(void)?
 
for (int i = 0; i < max; i++) {
    printf("%c", *(((char*)pv) + i));
}
printf("\n");

Ponteiro para void são utilizados quando precisa-se apontar para uma área genérica de memória sem ter controle/conhecimento do tipo de dados que essa área contém, ou em funções que não podem fazer suposições sobre os tipos de seus parâmetros, como é o caso da API da lib pthreads (link arbitrário).

Encerrando

Quanto mais nos aprofundamos nos tópicos sobre ponteiros, mais próximos da máquina ficamos. Boa parte do poder das linguagens C e C++ provém daí, e boa parte dos problemas também. A complexidade vai aumentando e os riscos também. Para muitos é aí que mora a diversão!

Links

• arrays.zip (todos os fontes do post);
• Ponteiros no cplusplus.com
• Ponteiros no blabos.org
• Referências no blabos.org
• O Culpado

Uma referência é um nome alternativo para um objeto, um alias. Aliás, quem diz isso não sou eu, mas o próprio Bjarne Stroustrup, lá pelo tópico 5.5 do seu livro, cujo conteúdo é tão bom que só fui reparar hoje que na capa tem uma onda quebrando em forma de C. Gostei dessa capa!

Declarando Referências

Uma referência para um determinado tipo é declarada acrescentando-se o caracter & (ê comercial ou ampersand) após o nome do tipo da referência. Note que da mesma forma que na declaração de ponteiros, estamos tratando o & como um caracter de notação e não um operador. Não há um operador de declaração de ponteiros ou referências. É apenas uma notação da linguagem. Dado um tipo T, a expressão T& significa Referência para T. Por exemplo:

// Declara uma variável inteira original.
// Também poderia ser char, float, etc.
int i;
 
// Declaram referências para a variável i.
// Todas as formas são equivalentes, mas preferimos a primeira.
// Note que os tipos das referências tem que ser os mesmos
// que os das variáveis referenciadas.
int& ra     = i;
int &rb     = i;
int & rc    = i;
 
// Diferentemente de ponteiros, a linha abaixo gera um
// erro de compilação. Você saberia dizer por quê?
int &r1, &r2;

Embora em C++ as referências lembrem um pouco os ponteiros, eles são bem diferentes. Ao contrário do que acontece com ponteiros, uma referência precisa ser inicializada durante sua declaração. Tentar declarar uma referência sem inicializá-la gera um erro em tempo de compilação, ou seja, o compilador vai cuspir na sua cara “Perdeu playboy, perdeu!”. A única exceção a essa regra é para referências declaradas como extern, pois elas serão inicializadas em algum outro ponto do programa, mas isso é outro papo.

Se você tentar trapacear declarando uma referência extern sem inicializá-la o compilador não vai reclamar. Se ela nunca for utilizada, ok. Se o compilador for esperto e notar que ela não será utilizada, pode até removê-la da lista de símbolos. Mas se ela for utilizada em qualquer parte do programa, o linker vai rir da sua cara gargalhando “undefined reference to ‘nome_da_variavel’”. Portanto faça as coisas direitinho. Declarou uma referência? Então iniclalize-a. extern? Tem certeza que sabe o que está fazendo?

A lógica por trás disso é que uma referência foi planejada para ser um nome para alguma coisa. Se você não a inicializar, ela não será nome para nada, então não faz sentido. Um detalhe muito importante é que inicializar uma referência não é atribuir um valor a ela. Como o prório Bjarne diz, nenhum operador opera sobre referências, ou seja, não há como atribuir, somar, subtrair, etc com uma referência. Como uma referência é um apelido para um objeto, cada operador atua nese objeto, e não na referência. Uma vez inicializada, uma referência sempre referenciará o mesmo objeto.

A primeira armadilha com referências, assim como ponteiros está na questão do tamanho. Enquanto o tamanho de um ponteiro (e de outras estruturas de dados) pode ser obtido com o operador sizeof, o tamanho de uma referência não pode ser obtido por técnicas convencionais, já que ao aplicar o operador sizeof em uma referência, estamos na verdade, aplicando o operador no objeto ao qual ela se referencia, conforme vimos no parágrafo anterior.

17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

char    c;
int     i;
double  d;
 
char&   rc = c;
int&    ri = i;
double& rd = d;
 
// O operador sizeof diz o tamanho do tipo do seu argumento.
cout << "Size of char:    " << sizeof(c) << " bytes" << endl;
cout << "Size of int:     " << sizeof(i) << " bytes" << endl;
cout << "Size of double:  " << sizeof(d) << " bytes" << endl;
 
cout << endl;
 
cout << "Size of char&:   " << sizeof(rc) << " bytes" << endl;
cout << "Size of int&:    " << sizeof(ri) << " bytes" << endl;
cout << "Size of double&: " << sizeof(rd) << " bytes" << endl;

As técnicas para obter os tamanhos das referências fogem ao escopo deste texto, mas pretendo falar sobre elas futuramente. Por hora, vou apenas dizer sem demonstrar que, quando aplicável, o tamanho de uma referência é idêntico ao tamanho de um ponteiro.

A parte boa da história é que frequentemente os tamanhos de ponteiros e referências são bem menos relevantes que os tamanhos dos objetos apontados ou referenciados. Eu particularmente, nunca precisei utilizar essa informação, mas para o desenvolvimento em arquiteturas diferentes ou para sistemas embarcados, isso já se torna mais interessante.

Utilizando Referências

O uso de referências já é bem mais simples que o de ponteiros, pois não são necessários operadores de extração de endereços ou de de-referenciação. Variáveis referências são utilizadas como variáveis comuns, lembrando que uma operação feita numa referência sempre afeta o objeto referenciado.

17
18
19
20
21
22
23
24
25
26
27
28
29
30

int x, y;
int& rx = x;
int& ry = y;
 
x = 13;
y = 10;
 
rx = 42;    // A atribuição é automaticamente aplicada em x.
ry++;       // O incremento é automaticamente aplicado em y.
 
cout << "x:  " << x << endl;    // Valor de x.
cout << "y:  " << y << endl;    // Valor de y.
cout << "rx: " << rx << endl;   // Valor de rx == x.
cout << "ry: " << ry << endl;   // Valor de ry == y.

Utilizar uma referência é tão transparente para o programador, que ele nem precisa saber que é uma referência. Simplesmente usa como se fosse uma variável ordinária. Com minha imaginação limitada não vejo como alguém consiga ser excomungado por utilizar referências inadequadamente. Embora sempre tenha algum espírito de porco que consiga fazer merda com referências, é muito mais fácil levar rasteira de Saci ao manusear ponteiros.

Endereços e Referências

Do ponto de vista de Murphy, as referências são feias, chatas e bobas, pois existe pouca coisa potencialmente perigosa a se fazer com elas. Nem mesmo quanto a endereçamento há muitas surpresas (será?). Considere o código abaixo:

17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

int a = 10;
int b = 13;
 
int& ra = a;
int& rb = b;
 
ra = 42;
rb = 7;
 
cout << "ra  = " << ra << endl;// O valor de ra == 42.
cout << "rb  = " << rb << endl;// O valor de rb == 7.
cout << "a   = " << a << endl; // O valor de a == ra == 42.
cout << "b   = " << b << endl; // O valor de b == rb == 7.
 
cout << "&a  = " << &a << endl; // O endereço de a.
cout << "&b  = " << &b << endl; // O endereço de b.
cout << "&ra = " << &ra << endl;// O endereço de ra == &a. 
cout << "&rb = " << &rb << endl;// O endereço de rb == &b.

Nas linhas 17 e 18 eu declaro duas variáveis inteiras (poderia ter feito esse exemplo com uma só…). Nas linhas 20 e 21 eu declaro duas referências, referenciando as duas variáveis anteriores. A partir desse momento as variáveis ra e rb são apenas apelidos para as variáveis a e b. Como vimos anteriormente, qualquer operador aplicado às referências, na verdade atua nos objetos referenciados, portanto cada par variável-referência possui sempre o mesmo valor.

A parte interessante a se notar é que os endereços das referências são exatamente os mesmo endereços das variáveis que elas referenciam, ao contrário dos ponteiros que tinham seus próprios endereços. Por quê? Porque você caiu na Pegadinha do Malandro. Lembra daquele papo de nenhum operador ser aplicável a uma referência? Pois bem, o & utilizado aqui é o operador “endereço de”, que também é aplicado diretamente nas variáveis originais e não nas referências. As mesmas técnicas ninja utilizadas para obter os tamanhos das referências são necessárias para se obter os endereços delas.

Novamente a parte divertida disso é que o mecanismo de referências foi planejado para ser o mais transparente possível para o programador. Tamanhos e endereços físicos de referências são informações irrelevantes do ponto de vista da programação “normal” em C++.

Diferenças e semelhanças entre Ponteiros e Referências

Tanto ponteiros como referências são mecanismos de indireção em C++, ou seja, são mecanismos utilizados para que a partir de um dado símbolo (variável) eu seja capaz de manipular outro objeto.

Os principais usos para ponteiros são geralmente relacionados com gerenciamento e manipulação dinâmica de memória, criação e destruição de objetos de formas e em momentos especiais, bem como “passagem de parâmetros por referência” (assim entre aspas mesmo). Já as referências são mais utilizadas em passagem por referência (por que será?) e sobrecarga de operadores.

Basicamente, tudo que podemos fazer com referências pode ser emulado com ponteiros. Já a recíprocra não é sempre verdadeira. A grande vantagem delas no entanto, é o fato de tornarem a indireção completamente transparente ao programador.

Uma alegoria interesante para ajudar a entender melhor as diferenças entre ponteiros e referências é o apelido. Por exemplo: Imagine que um pessoa, digamos, Carlos Caetano Bledorn Verri, seja a nossa variável original, o objeto. Dunga já é uma referência a Carlos Caetano Bledorn Verri, pois é um apelido para o mesmo objeto, são a mesma pessoa. Já a Mãe do Dunga (ou do Carlos Caetano Bledorn Verri, tanto faz), que é contantemente citada pela torcida, pode ser considerada um ponteiro para ele, pois dados determinados operadores de vocabulário, um elogio feito a ela, na verdade é indiretamente direcionado a ele.

Links

• referencias.zip (todos os fontes do post);
• 01-declaracao.cpp
• 02-tamanhos.cpp
• 03-utilizando.cpp
• 04-enderecos.cpp
• O Culpado

Ponteiro é um tipo especial de dado, cujas variáveis declaradas desse tipo podem apontar (ou não) para algum outro dado na memória. Uma variável do tipo ponteiro, guarda o endereço de um outra coisa na memória. Essa coisa pode ser alguma variável, constante, início de um conjunto de dados, uma função, entre outras.

Declarando Ponteiros

A declaração de um ponteiro é normalmente feita acrescentando-se um * antes do nome da variável. Uma notação muito utilizada cola o * ao nome do tipo para dizer simbolicamente que se está declarando um “ponteiro para o tipo”, ao invés de uma “variável ponteiro”, mas elas são equivalentes. Por exemplo:

// Ponteiro para um int.
int* ptr_num1;
 
// Ou assim.
int *ptr_num2;
 
// Ponteiro para um double.
double* ptr_double1;
 
// Ou assim.
double *ptr_double2;

Depois de declarado, o ponteiro existe, possui tamanho e consequentemente ocupa lugar na memória. O tamanho de um ponteiro geralmente é igual ao número de bits da máquina/sistema em questão, por exemplo 4 bytes num sistema 32 bits.

17
18
19
20
21
22
23
24
25
26
27
28
29
30

char    c, *pc;
int     i, *pi;
double  d, *pd;
 
// O operador sizeof diz o tamanho do tipo do seu argumento.
cout << "Size of char:    " << sizeof(c) << " bytes" << endl;
cout << "Size of int:     " << sizeof(i) << " bytes" << endl;
cout << "Size of double:  " << sizeof(d) << " bytes" << endl;
 
cout << endl;
 
cout << "Size of char*:   " << sizeof(pc) << " bytes" << endl;
cout << "Size of int*:    " << sizeof(pi) << " bytes" << endl;
cout << "Size of double*: " << sizeof(pd) << " bytes" << endl;

Utilizando Ponteiros

Após a sua declaração, o conteúdo de um ponteiro é um valor aleatório, lixo de memória, como qualquer variável. Para que ele seja útil precisamos atribuir algo a ele. Como um ponteiro guarda um endereço de memória, precisamos atribuir a ele um endereço válido.

17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

int x, y;
int *px, *py;
 
x = 13;
y = 10;
 
px = &x;
py = &y;
 
*px = 42;
(*py)++;
 
cout << *px << endl;
cout << *py << endl;
cout << (*px) * (*py) << endl;

O operador & (ê comercial ou ampersand) antes do nome de uma variável significa “o endereço de”, até porque o seu nome é “endereço de”.

O que está à esquerda da igualdade tem que poder guardar exatamente o mesmo tipo do que estiver do outro lado da igualdade. Um ponteiro guarda um endereço. Portanto para atribuir um endereço a um ponteiro, neste caso, é preciso obter um endereço com o operador &.

Exceto nos caso em que há conversão implícita de tipos (como entre tipos numéricos), atribuir a uma variável algo com um tipo diferente do seu, causa um erro de compilação. Felizmente!!!

Depois que um ponteiro já apontar para um endereço válido, poderemos acessar o conteúdo desse endereço com o operador * (Asterisco), cujo nome formal é “operador de de-referência”.

Note que o asterisco em uma declaração significa “ponteiro para o tipo” e no contexto da leitura ou escrita do conteúdo de um ponteiro, significa “o conteúdo do endereço” ou “o conteúdo apontado por”. Também cuidado para não confundir com o símbolo para produto aritmético. Para não confundir, lembre-se daquela tabela enorme de precedência dos operadores, que você só passou o olho e deixou cair no esquecimento. Nela você vai encontrar que o operador de de-referência tem precedência sobre o operador de multiplicação. Feito isso você vai se lembrar que o operador de de-referência é avaliado ANTES do operador de multiplicação.

17
18
19
20
21
22
23
24
25
26
27
28
29
30

int a, b, c, *pa, *pb;
a = 2;
b = 3;
 
pa = &a;
pb = &b;
 
c = *pa * *pb;
c = *pa * * pb;
c = * pa * * pb;
c = *pa**pb;
c = (*pa) * (*pb);
 
cout << "Valor da Pegadinha: " << c << endl;

Assim quando aquela prova de algoritmos te perguntar o que faz qualquer uma das últimas 5 linhas do exemplo, você vai dizer que ela multiplica os conteúdos apontados por pa e pb. Não vai mais precisar pegar DP por causa disso! E de quebra na vida real, se você realmente precisar fazer isso, você vai salvar suas 4 gerações passadas e as 5 futuras da excomunhão, se escolher usar a última linha.

Tudo que é possível fazer com uma variável comum é possível fazer com o conteúdo apontado por um ponteiro, seja leitura ou escrita (a menos é claro que o ponteiro seja const, mas isso é outro papo…).

Endereços e Ponteiros

Tomemos como exemplo o código abaixo:

18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97

int a, b;
int *pa, *pb;
 
printf("Antes de qualquer atribuição:\n");
 
printf("&a  = %p\n", &a); // Endereço válido dado pelo SO.
printf("&b  = %p\n", &b); // Endereço válido dado pelo SO.
printf("&pa = %p\n", &pa);// Endereço válido dado pelo SO.
printf("&pb = %p\n", &pb);// Endereço válido dado pelo SO.
 
printf("\n");
 
printf("a   = %d\n", a);  // Conteúdo não inicializado (aleatório).
printf("b   = %d\n", b);  // Conteúdo não inicializado (aleatório).
printf("pa  = %p\n", pa); // Conteúdo não inicializado (aleatório).
printf("pb  = %p\n", pb); // Conteúdo não inicializado (aleatório).
 
// Tente descomentar as linhas abaixo, recompilar e rodar.
//printf("*pa  = %d\n", *pa); // O que será (*aleatório)?
//printf("*pb  = %d\n", *pb); // O que será (*aleatório)?
 
printf("\nApós as inicializações dos ponteiros:\n");
 
pa = &a;
pb = &b;
 
printf("&a  = %p\n", &a); // Mesmo endereço válido dado pelo SO.
printf("&b  = %p\n", &b); // Mesmo endereço válido dado pelo SO.
printf("&pa = %p\n", &pa);// Mesmo endereço válido dado pelo SO.
printf("&pb = %p\n", &pb);// Mesmo endereço válido dado pelo SO.
 
printf("\n");
 
printf("a   = %d\n", a);  // Conteúdo não inicializado (aleatório).
printf("b   = %d\n", b);  // Conteúdo não inicializado (aleatório).
printf("pa  = %p\n", pa); // Conteúdo inicializado (&a).
printf("pb  = %p\n", pb); // Conteúdo inicializado (&b).
 
printf("*pa = %d\n", *pa);// Conteúdo apontado por pa (*pa == a).
printf("*pb = %d\n", *pb);// Conteúdo apontado por pb (*pb == b).
 
printf("\nApós as inicializações dos inteiros:\n");
 
a = 10;
b = 13;
 
printf("&a  = %p\n", &a); // Mesmo endereço válido dado pelo SO.
printf("&b  = %p\n", &b); // Mesmo endereço válido dado pelo SO.
printf("&pa = %p\n", &pa);// Mesmo endereço válido dado pelo SO.
printf("&pb = %p\n", &pb);// Mesmo endereço válido dado pelo SO.
 
printf("\n");
 
printf("a   = %d\n", a);  // Conteúdo inicializado (10).
printf("b   = %d\n", b);  // Conteúdo inicializado (13).
printf("pa  = %p\n", pa); // Conteúdo inicializado (&a).
printf("pb  = %p\n", pb); // Conteúdo inicializado (&b).
 
printf("*pa = %d\n", *pa);// Conteúdo apontado por pa (*pa == a == 10).
printf("*pb = %d\n", *pb);// Conteúdo apontado por pb (*pb == b == 13).
 
printf("\nAlterando os valores através dos ponteiros:\n");
 
*pa = 7;
*pb = 42;
 
printf("&a  = %p\n", &a); // Mesmo endereço válido dado pelo SO.
printf("&b  = %p\n", &b); // Mesmo endereço válido dado pelo SO.
printf("&pa = %p\n", &pa);// Mesmo endereço válido dado pelo SO.
printf("&pb = %p\n", &pb);// Mesmo endereço válido dado pelo SO.
 
printf("\n");
 
printf("a   = %d\n", a);  // Conteúdo inicializado (a == *pa ==  7).
printf("b   = %d\n", b);  // Conteúdo inicializado (b == *pb == 42).
printf("pa  = %p\n", pa); // Conteúdo inicializado (&a).
printf("pb  = %p\n", pb); // Conteúdo inicializado (&b).
 
printf("*pa = %d\n", *pa);// Conteúdo apontado por pa ( 7).
printf("*pb = %d\n", *pb);// Conteúdo apontado por pb (42).

As linhas 18 e 19 declaram respectivamnete dois inteiros e dois ponteiros para inteiros.

As linhas 23 a 26 mostram os endereços das minhas variáveis. Esses endereços foram dados pelo sistema operacional e são fixos enquanto essas variáveis existirem. Uma variável não muda de endereço durante a execução do programa, mas pode mudar entre uma execução e outra. Quem define qual é esse endereço é o sistema operacional no momento da execução do programa. O compilador só sabe que serão necessários x bytes para cada variável, e qual a interpretação (tipo) que o programa vai dar a esse espaço.

As linhas 30 a 33 mostram os conteúdos dessas variáveis, que ainda não foram inicializadas. É lixo, o último valor que alguém (não sei quem) colocou naqueles lugares da memória do computador e que agora pertencem às minhas variáveis.

Note que não é seguro descomentar as linhas 36 e 37 pois elas tentam acessar os conteúdos apontados por pa e pb, que ainda não foram inicializados. Durante essa tentativa, o programa vai tentar interpretar aqueles valores de lixo aleatório como se fossem endereços de variáveis int válidos. Dependendo do compilador, do SO utilizado e da sua sorte, pode ser algo inofensivo ou não. O certo é que o resultado dessas linhas é imprevisível e fonte certa de problemas.

Nas linhas 41 e 42 os ponteiros são inicializados com os endereços das variáveis inteiras a e b. A partir daí os prints são repetidos.

Veja que os endereços dos ponteiros não mudam, o que já era esperado. O que mudam são os seus conteúdos. As variáveis pa e pb recebem os endereços de a e b respectivamente. Note que o conteúdo dos ponteiros é exatamente o valor do endereço das variáveis a e b que foram dados pelo SO no início do programa. Confira com os prints anteriores. O conteúdo apontado por pa e pb é o mesmo conteúdo de a e b, que ainda não foram inicializados, ou seja, lixo. Porém, diferentemente da etapa anterior, agora os ponteiros apontam para endereços válidos (os endereços de a e b) e ainda que os conteúdos de a e b sejam lixo de memória, os ponteiros agora apontam para variáveis que já foram alocadas.

Nas linhas 61 e 62 as variáveis inteiras são inicializadas com os valores 10 e 13, e os prints repetidos denovo.

Desta vez os coteúdos de a e b não são mais lixo. São valores devidamente conhecidos. Note que não há nenhuma alteração no endereçamento das variáveis em relação às etapas anteriores, apenas nos valores.

Veja também que depois que a e b foram inicializados, o conteúdo apontado por pa e pb também foram alterados automaticamente. Isto acontece justamente porque pa e pb apontam para as mesmas áreas de memória utilizadas pelas variáveis pa e pb. Isso significa que o conteúdo apontado por um ponteiro pode ser modificado alterando-se o conteúdo das variáveis originais apontadas por ele. E finalmente as linhas 81 a 97 mostram que o inverso também vale, ou seja, alterando-se o conteúdo apontado por um ponteiro, altera-se automaticamente o conteúdo das variáveis originais apontadas por eles.

É mais fácil entender isso pensando nas frases em português do que olhando para o código.

Por enquanto…

Este foi o básico da operação com ponteiros. Ainda existem coisas interessantes para serem vistas, como ponteiros para funções, por exemplo, mas isso já é considerado um tópico mais avançado. Na sequência desta série, que está planejada para 4 posts, veremos referências, diferenças e semelhanças entre ponteiros e referências e por último ponteiros para funções.

Links

• ponteiros.zip (todos os fontes do post);
• 01-declaracao.cpp
• 02-tamanhos.cpp
• 03-utilizando.cpp
• 04-pegadinha.cpp
• 05-enderecos.cpp
• Ponteiros no cplusplus.com
• O Culpado

Um colega de trabalho mais experiente estava explicando para um outro colega menos experiente que para cada new deve haver um respectivo delete. Caso contrário o objeto persistirá em memória podendo ocorrer memory leaks.

Nesse momento eu o interrompi e disse que “não necessariamente, pois basta que o objeto saia de escopo para que o destrutor seja chamado automaticamente.”.

A partir daí rolou uns 10 min de debate com argumentos e contra-argumentos, tendo toda a equipe parada assistindo. No final, metade da equipe concordava com ele e a outra metade comigo, e naquele momento ninguém tinha na cabeça uma forma de checar pra ver. Olhar na internet não era uma opção.

Como eu tinha todas as respostas, afinal já programava em PHP, Java e C++ fiquei de demonstrar posteriormente que eu estava certo.

Dias depois, num daqueles momentos filosóficos, lembrei que um endereço na memória é um número, e que é possível tanto converter um endereço para um número comum, quanto fazer o caminho inverso, embora a segunda opção normalmente seja inútil.

Bolei então uma forma de provar a minha teoria: Criaria um objeto num escopo restrito alocando com new. Guardaria o endereço desse objeto como um número comum num long fora do escopo restrito, esperaria o escopo restrito finalizar, o destrutor do obejto ser chamado e então, no escopo externo, usaria o número que representava o endereço do objeto para acessar aquela área de memória mostrando que receberia um SIGSEGV (segmentation fault) por tentar acessar uma área de memória inválida. Gerei então o código abaixo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

#include <iostream>
#include <string>
 
using namespace std;
 
int main(int argc, char** argv) {
    unsigned long num = 0;
 
    {
        string* str = new string("Hello World!!!");
        num = (unsigned long)str;
 
        cout << "str: " << str <<  endl;
        cout << "num: " << num <<  endl;
    }
 
    cout << *((string*)num) << endl;
 
    return 0;
}

Eis que para minha surpresa o programa NÃO explodiu na minha cara. Ele funcionava corretamente demonstrando que na verdade EU era quem estava errado.

Pesquisando mais constatei que sim, para cada new deve haver um e somente delete, e mais, para cada new[] deve haver um e somente um delete[]. O que eu achava que sabia sobre gerenciamento de memória e escopos, provavelmente era alguma confusão entre diferentes linguagens.

Quando eu iniciei a discussão dias antes, eu cometi todos os erros básicos que um newbie comete:

1. Se meter onde não foi chamado.
2. Jurar de pé junto que está certo sem ter provas.
3. Subestimar o conhecimento de alguém mais experiente.
4. Achar que tem todas as respostas só porque acabou de ver isso na aula.
5. Achar que só porque conhece o básico de várias linguagens, então tem todas as respostas.

Como todo bom integrante da espécie dos Homo sapiens, falei merda. A minha reação a esta descoberta foi assumir para e equipe inteira que eu estava errado, pedir desculpas por ter falado besteira e mostrar essas vinte linhas de código que usei para demonstrar isso. Além disso, mostrei todas as fontes que pesquisei, e ainda trouxe à tona outros detalhes sobre gerenciamento de memória que nos estavam escapando, como referências circulares. Isso levou até a um re-desing de algumas partes do projeto.

As minhas 20 linhas de cógigo ficaram conhecidas como “As 20 linhas da vergonha” e natualmente eu fui sacaneado por isso. Cada vez que alguém tinha alguma dúvida falavam “faz aí as 20 linhas da vegonha pra testar”. O significado era mais ou menos como “faz aí um teste simples pra não passar vergonha depois”.

O mais importante é que a minha atitude pós-cagada foi bem aceita e trouxe benefícios para a equipe. Se eu tivesse me esquivado, mais cedo ou mais tarde alguém ia provar que eu estava errado na frente de todo mundo, ou pior, nos bastidores. Admitir o erro e aprender com isso mostrou que eu estava preparado para ser contestado. Adicionalmente isso mostrou para equipe que por mais que eu parecesse arrogante (eu pareço mais do que sou…), eu sabia que era um humano comum, que errava como qualquer um, não me achando superior a ninguém. Isso abriu caminho para que outros membros da equipe se sentissem à vontade para fazer o mesmo e nós nos tornamos uma equipe ainda mais coesa.

É claro que não é o tipo de coisa que deve ser usada para torturar um netbook, pois ele não foi desenhado para ser uma estação de desenvolvimento. Tanto é que ao final da instalação acabou o espaço disponível em disco, que já não era muito. Em termos de desempenho também não fica lá essas coisas, afinal é um NETbook, não un NOTEbook.

Passo #0: Instalação do Java

Desta vesta vez ao invés de instalar a JRE na mão, utilizamos o synaptic, onde é só mandar procurar, clicar e instalar. Eu me contento com as versões disponíveis do java. Para maiores detalhes, seguem os links habituais: Download do Java e Dicas de Instalação.

Passo #1: Instalação do Eclipse

Eu vou continuar baixando e instalando o eclipse diretamente do seu site, pois a versão disponibilizada via synaptic é velha demais para mim . Eu preferi o eclipse SDK, aquele que vem com o Java ao invés do CDT. Mas você pode escolher qualquer um.

Feito o download, um duplo clique no arquivo abre o descompactador. Daí é só mandar extrair em algum diretório à sua escolha. Eu preferi deixar no ~/local, já que ficando no meu home, não vou precisar de permissão de administrador para instalar.

Eu também precisei baixar o ícone, pois ou no pacote não tem, ou está escondido demais para mim.

Passo #2: Instalando o CDT

Para isso bastar abrir o eclipse e ir em Help>Softwares Updates procurar po cdt e mandar ver na instalação. Ao terminar, o eclipse pede para ser reiniciado. Como pessoa bondosa que sou eu respondo sim cada vez que ele me pergunta.

Passo #3: Integração com o Subversion

Esse é um pouco menos fácil. Vá em Help>Softwares Updates e procure por, advinhe? mylyn. Pra começar a brincadeira isso vai ser necessário para a instalação da integração com Subversion. Daí o de sempre, next, nex, install. Depois, Help>Softwares Updates procure por svn e mais uma vez, next, next, install. O problema é que isso vai instalar somente a integração (???), ainda faltam os conectores (???), ou seja, integra, mas não integra tanto assim…

A instalação dos conectores é feita via um site próprio. Mas cuidado agora, a menos que você esteja no windows, evite os pacores win32, óbvio. Isso vai te poupar muitas dores de cabeça, pois o eclipse é meio tímido quando o assunto é sobre os erros. Feito isso, next, next, install, e reiniciar o eclipse denovo…

Passo #4: Integração com Perl

A integração com Perl é bem simples de ser instalada, bastando adicionar o site do EPIC e mandar ver no next, next, install…

Passo #5: Qt Eclipse Integration

Pra variar, nada de next, next, intall. Desta vez, é baixar do site da TrollTech Qt Software, duplo clique e mandar descompactar no mesmo diretório que o eclipse foi descompactado, no meu caso ~/local. Nâo é dentro do diretório do eclipse, é fora, no mesmo nível, pois o arquivo da integração com o Qt vai criar um diretório eclipse/ onde for descompactado e esse diretório precisa combinar com o diretório do eclipse.

Passo #6: Web Tools

Ultimamente eu ando me arriscando denovo no mundo do desenvolvimento web com o Catalyst. Por isso algumas ferramentas como um editor de html ajudam muito. Eu usava o kate, mas agora descobri os plugins do próprio eclipse. Então, mãos à obra, pra variar, Help>Softwares Updates, procurar por web e então next, next, install.

Passo #7: Vim Plugin

Por último e não menos importante não dá pra deixar o Eclipse completo, sem integrá-lo com o mais importante IDE de todos os tempos, o VIM.

Por ser o Vim uma ferramenta de “modo texto”, a instalação do Vim Plugin não tem screen shots . Mas não se preocupem, basta acessar o site dele e seguir as poucas intruções. Não se esqueçam de marcar no eclipse a opção ‘Embed Vim’ pois senão ao abrir os arquivos ele vai abrir uma janela nova.

Considerações Finais

A nova versão do Eclipse, Ganymede, está bem mais produtiva e fácil de instalar. Já é até possível instalar a maioria dos plugins sem muita dor de cabeça. A integração com o Qt e Subversion, por exemplo, são duas mãos na roda principalmente para os desenvolvedores independentes. As ferramentas de edição de HTML, apesar de deixarem um pouco a desejar, também estão muito boas.

Para o meu workspace ser perfeito só faltava o Eclipse ser bonito como o QtCreator, o EPIC funcionar como a parte do Padre que funciona e o plugin do VIM ser um pouco mais decente, mas afinal não dá pra copiar o VIM, né…

Links Interessantes

• Eclipse.org
• Qt Software
• QtCreator
• Polarion Community
• SVN Redbook
• EPIC – Eclipse Perl Integration
• Padre – Perl IDE
• VIM Plugin

Estou lendo certo, Orientação a Objetos em ANSI C?

Sim e não!

Coisas como herança, polimorfismo e sobrecarga são complicadas de fazer/emular em C, mas você pode programar utilizando um estilo que se comporte de forma semelhante à orientação a objetos. A libdfb é escrita em C mas “orientada a objetos”, de forma que você cria, manipula de destrói elementos que se comportam de forma bem semelhante a objetos.

Aqui no trabalho, temos um sistema de abstração de hardware em C que se conecta com uma GUI em C++. A camada mais baixa, em C também foi escrita (e muito bem escrita, diga-se de passagem) com essas técnicas, simulando uma orientação a objetos. Uma dessas técnicas, me chamou atenção por usar uma daquelas notas de rodapé dos livros de C.

Ao compilar código em C, cada símbolo só tem visibilidade dentro da unidade de compilação na qual ele foi declarado, a menos que seja declarado novamente nas outras unidades como extern. Dessa forma, é possível “esconder” certos símbolos dentro de sua unidade de compilação, tornando-os inacessíveis ao mundo exterior. Temos com isso encapsulamento.

A unidade de compilação é o conjunto de arquivos que depois de pre-processados e compilados geram um único código objeto. Basicamente (mas não exatamente), podemos tomar como unidade de compilação cada arquivo de implementação de código fonte (*.c, *.cpp. etc). Maiores detalhes sobre as etapas de compilação em C e C++ podem ser encontrados no blog do Caloni.

Utilizando essas informações, podemos criar uma struct em ANSI C na qual os seus membros internos são “privados”. A mágica está em aprisionar a definição dos membros dentro da unidade de compilação e criar métodos de acesso para esses membros. Para isso usamos as notas de rodapé que nos mostram a diferença entre declaração e definição de elementos em C:

Declaração ou manifesto: Apresenta ao compilador um identificador sem dizer muito sobre seu significado, ou seja, diz ao compilador que o identificador XXX existe, mas pouco se sabe sobre o que ele representa.
Ex.:

extern int a;
void bla(void);
struct st_data;

Definição ou implementação: Diz ao compilador o que determinado identificador representa, como por exemplo quanto de memória deve ser alocada para ele e qual o endereço de memória onde podemos encontrá-lo, entre outras coisas.
Ex.:

int a;
void bla(void) {/* Do anything.  */}
struct st_data {/* Some members. */}

Quando falamos de estruturas e tipos, sem a definição o compilador não tem como alocar memória para eles pois nada se sabe a respeito de quanto espaço uma variável daquele tipo precisa. Por outro lado, algumas vezes, sem a declaração, o linker não tem como saber que aquele símbolo existe.

Quando declaramos uma estrutura num cabeçalho, normalmente nós também definimos seus membros ali mesmo e toda vez que adicionamos esse cabeçalho a um fonte nosso, nós incluimos na unidade de compilação desse fonte tanto a declaração quanto a definição dessa estrutura, tornando os membros da estutura públicos à essa unidade de compilação. Isso nos permite acessar seus membros diretamente.

Se separarmos a declaração da definição, somente símbolo que representa a estrutura estará disponível, mas não os seus membros. Assim, qualquer tentativa de acesso direto a um membro, gerará um erro de compilação. Um efeito colateral interessante é que como o compilador nada sabe sobre o tamanho da estrutura, não será possível definir diretamente uma variável do tipo da estrutura, somente um ponteiro para ela, pois ponteiros têm todos o mesmo tamanho e o compilador precisa apenas do nome símbolo do tipo para criar o ponteiro.

Temos então o header mytype.h mais ou menos assim:

#ifndef MY_TYPE_H
#define MY_TYPE_H
 
/* O typedef é apenas pra não ficar repetindo a palavra struct. */
/* A declaração é somente o trecho:                             */
/* struct _mytype                                               */
typedef struct _mytype my_type;
 
void create_my_type( my_type** );
void destroy_my_type( my_type** );
 
void set_data( my_type* , int );
int get_data( my_type* );
void set_text( my_type* , const char* );
char* get_text( my_type* );
 
#endif

A implementação mytype.c:

#include "mytype.h"
 
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
struct _mytype {        /* Aqui fica a definição da estrtura. */
    int data;           /* Somente depois disso é que o com-  */
    int text[21];       /* pilador vai saber como alocá-la.   */
};                      /* Tente um sizeof(my_type) no main.  */
 
void create_my_type( my_type** my_ptr )             { /* some code... */ }
void destroy_my_type( my_type** my_ptr )            { /* some code... */ }
void set_data( my_type* my_ptr , int d )            { /* some code... */ }
int get_data( my_type* my_ptr )                     { /* some code... */ }
void set_text( my_type* my_ptr , const char* text ) { /* some code... */ }
char* get_text( my_type* my_ptr )                   { /* some code... */ }

O código fonte completo do exemplo pode ser encontrado aqui.

Como não é possível criar diretamente variáveis desse tipo, precisamos definir um “construtor” e um “destrutor”.

Tentativas de acesso direto a membros geram erro de compilação:

user@host:~/private-struct-members$ gcc -o teste mytype.h mytype.c main.c
main.c: Na função ‘main’:
main.c:22: erro: dereferencing pointer to incomplete type
user@host:~/private-struct-members$

Dessa forma, com um pouco de criatividade e tendo os conceitos tanto da linguagem quanto dos paradigmas, é possível implementar códigos realmente interessantes. Neste exemplo bobo talvez não tenha ficado clara a utilidade de forçar uma emulação de encapsulamento ou o uso de construtor/destrutor em C, mas em sistemas onde as circunstâncias não permitem um C++, ou que a complexidade tenda a atingir níveis críticos, essas técnicas se mostram de grande valia. No nosso caso, essa técnica especificamente, permitiu que um programador experiente, que não participou do projeto todo, descobrisse que sua tentativa de acesso direto a um membro de uma estrutura, estava contextualmente inadequada. Sem isso, um bug cabuloso de lógica iria aparecer somente em tempo de execução, provavelmente fazendo o software explodir na cara do cliente.

Links úteis (ou não…):
http://www.directfb.org
http://www.caloni.com.br
http://www.numaboa.com.br/informatica/c/
Livro Desenvolvimento do Kernel do Linux

Os comandos que afetam diretórios fora de seu home, precisarão de permissão de superusuário.

Se você resolveu instalar o eclipse apartir dos pacotes disponíveis em sua distribuição, pode pular direto para o passo #2.

Passo #0: Instalação do Java

Para que o eclipse funcione, vc precisa do Java Runtime Environment (JRE) instalado *E* configurado.

O JRE pode ser baixado direto do site da Sun http://java.sun.com/javase/downloads/index.jsp. Instruções completas de instalação e configuração podem ser encontradas em http://java.sun.com/javase/6/webnotes/install/index.html, para o caso do JRE 6.

Passo #1: Donwload e instalação do eclipse

O eclipse pode ser facilmente baixado a partir da área de downloads no seu site oficial: http://www.eclipse.org/downloads. Após o download, basta descompactá-lo e sair usando. No meu caso eu usei:

user@host$ tar -xvzf eclipse-cpp-europa-winter-linux-gtk.tar.gz -C /usr/local

Se tudo deu certo o executável do eclipse estará em /usr/local/eclipse/eclipse, daí é só criar um link/atalho/whatever no seu ambiente gráfico favorito.

Passo #2: Download e instalação do plugin de integração com o QT

O plugin que eu atualmente uso é o fornecido pela própria Trolltech. Nele você pode gerenciar os seus arquivos de projeto a partir de um pequeno editor gráfico, e ainda se preferir, tem acesso direto ao arquivo .pro.

O download pode ser feito a partir de http://trolltech.com/developer/downloads/qt/eclipse-integration-download, e a instalação cujas instruções completas podem ser encontradas em http://trolltech.com/developer/downloads/qt/qteclipse-installmanual, é complicadíssima:

user@host$ tar -xvzf qt-eclipse-integration-linux.x86-gcc3.3-1.4.0.tar.gz -C /usr/local

Se tudo deu certo, os arquivos do plugin foram copiados para o diretório /usr/local/eclipse/plugins.

Nota: Para quem optou pela instalação do eclipse através dos pacotes da distribuição, atenção!!! Dentro do arquivo compactado, há o diretório eclipse/plugins/, e dento dele os arquivos do plugin, que devem ser copiados para o diretório de plugins da instalação do seu eclipse, normalmente /usr/lib/eclipse/plugins.

Após a instalação, inicie o eclipse com o comando:

user@host$ /usr/local/eclipse/eclipse -clean

Agora, vá em Window>Preferences>Qt e ajuste a versão e os “pathes”, de acordo com a sua instalação do Qt.

Para ficar mais cômodo, se você invoca o eclipse direto da linha de comando, adicione o diretório do seu executável na variável de ambiente $PATH, dentro de algum dos scripts de inicialização (.bash_profile)

export PATH=$PATH:/usr/local/eclipse

Passo #3: Subversion

No eclipse vá em Help>Softwares Updates>Find and Install. Marke a opção Search for new features to install e clique em Next. Agora adicione os sites remotos:

Buckminster

http://download.eclipse.org/tools/buckminster/updates

SubClipse

http://subclipse.tigris.org/update_1.2.x

Marque os respectivos checkboxes, e clique em Finish. Depois de uma pequena consulta à internet, é só marcar o plugin e dependências e correr pro abraço.

O qmake

O qmake é um utilitário que acompanha o framework QT. Sua função é parsear um arquivo de projeto (*.pro) e gerar um Makefile já com as regras do moc, uic e opções do QT embutidas. Sem ele por exemplo, teríamos que chamar o moc explicitamente para criar os arquivos moc_* e passar explicitamente para o compilador e linker, as opções corretas para incluir o QT aos nossos projetos.

A documentação oficial sobre o qmake e arquivos de projeto, pode ser encontrada aqui.

Arquivos de projeto *.pro

Para criar um arquivo de projeto simples pela linha de comando, entramos no diretório do projeto e digitamos:

user@host$ qmake -project

Feito isso, será criado um arquivo com o mesmo nome do diretório corrente, seguido da extensão .pro. Caso já existam nesse diretório arquivos reconhecidos pelo qmake, como arquivos de códigos fontes (.h, .cpp), forms (.ui), etc, eles serão automaticamente adicionados ao arquivo de projeto.

Criado o arquivo .pro, ao executarmos qmake sem argumentos ele tentará parsear um arquivo .pro com o mesmo nome do diretório corrente. Você ainda pode especificar um arquivo de projeto alternativo como argumento para o qmake. Se tudo deu certo, um arquivo Makefile foi criado, e com um simples make, podemos compilar o projeto.

Os arquivos de projeto são arquivos de texto normais, contendo macros e diretivas que serão interpretadas pelo qmake para criar o Makefile. A lista completa de opções pode ser encontrada na documentação online. As mais comuns são:

TEMPLATE: Indicam o tipo de projeto. Use ‘app’ para proramas executáveis ou ‘lib’ para criar bibliotecas.

CONFIG: Adicionam opções diversas ao projeto. Entre elas, ‘debug’ para adicionar informações de depuração, ’staticlib’ em conjunto com o template ‘lib’, para que abiblioteca criada seja estática (.a no linux).

TARGET: O nome e a localização do alvo, ou seja, do aplicativo ou biblioteca.

MOC_DIR: Diretório onde serão grados os arquivos moc_*. Útil para não poluir o diretório de códigos fontes.

OBJECTS_DIR: Complementar à opção anterior, indica o diretório onde serão gerados os aquivos de código objeto (*.o).

INCLUDEPATH: Diretórios externos onde existem headers que serão utilizados no projeto, como headers de bibliotecas externas.

DEPENDPATH: Diretórios de códigos fontes externos que serão utilizados pelo projeto.

HEADERS: Os arquivos de cabeçalho do projeto (*.h).

FORMS: arquivos de interface gerados com o QtDesigner (*.ui).

SOURCES: Os arquivos de implementação de código fonte do projeto (*.cpp).

LIBS: Bibliotecas externas utilizadas pelo projeto. -L indica o path para a biblioteca, e -l diz o nome da biblioteca.

QT: Módulos do QT que devem ser adicionados/excluidos do projeto. Se for passado ‘QT =’ (QT igual vazio), nenhum módulo QT será utilizado no projeto.

SUBDIRS: Utilizado em conjunto com o template ’subdirs’, indica os subdiretórios ons o qmake deve procurar por outros arquivos de projeto.

Com isso em mãos podemos criar algums projetos simples.

Um aplicativo simples:

# O primeiro caracter desta linha cria um comentário
# O nome deste arquivo é 'app.pro'
TEMPLATE     =  app            # Nosso template é um aplicativo chamado
TARGET       =  bin/myapp.bin  # myapp.bin, dentro do dir ./bin
MOC_DIR      =  tmp/moc        # Diretório para mocs, opcional
OBJECTS_DIR  =  tmp/obj        # Diretório para código objeto, opcional
HEADERS      += myclass.h      # Header da classe MyClass
SOURCES      += main.cpp      # Utilize  para organizar os arquivos em
                myclass.cpp    # várias linhas.

Uma biblioteca simples:

# O nome deste arquivo é 'lib.pro'
TEMPLATE     =  lib            # Nosso template é uma biblioteca
CONFIG       += dll            # dinâmica, chamada
TARGET       =  lib/mylib      # mylib, dentro do dir ./lib
MOC_DIR      =  tmp/moc        # Diretório para mocs, opcional
OBJECTS_DIR  =  tmp/obj        # Diretório para código objeto, opcional
HEADERS      += myclass.h      # Header da classe MyClass
SOURCES      += myclass.cpp    # Implementação da classe MyClass

Um aplicativo que usa uma biblioteca externa:

# O nome deste arquivo é 'mixed.pro'
TEMPLATE     =  app            # Nosso template é um aplicativo chamado
TARGET       =  bin/myapp.lkd  # myapp.lkd, dentro do dir ./bin
MOC_DIR      =  tmp/moc        # Diretório para mocs, opcional
OBJECTS_DIR  =  tmp/obj        # Diretório para código objeto, opcional
INCLUDEPATH  += .              # Dir onde estão os Headers da lib externa
SOURCES      += main.cpp       # Implementação do aplicativo.

Diretórios aninhados:

Para utilizarmos diretórios aninhados, precisamos de um arquivo de projeto no diretório atual, e outro no subdiretório.

No diretório atual, utilizamos as opções:

TEMPLATE = subdirs
SUBDIRS  = [lista de subdirs para serem compilados em sequência]

Caso seja fornecido apenas o nome do diretório, ele precisa conter uma arquivo de projeto com o seu próprio nome. É possível no entando, informar diretamente na lista de subdiretórios, um diretório seguido por um arquivo de projeto com quaquer nome.

O código fonte completo dos exemplos abordados neste tutorial pode ser encontrado aqui.

Concluindo

O qmake é uma ferramenta simples e muito poderosa que facilita enormemente a vida de quem tem de gerenciar aŕvores de projeto complexas, mesmo que o projeto não utilize QT (basta acrescentar no final a opção ‘QT = ‘). Adicione a isso o fato de os arquivos de projeto terem uma sintaxe bastante simples e até certo ponto intuitiva. Se você precisar de ajustes mais finos, a documentação online lhe dará uma dezena de opções para se divertir.

Com QT ou sem QT, o qmake é sempre uma boa opção para gerenciamento de árvore de build.

Requisitos:

• Linguagens C, C++ ou Java;
• Linux para sitemas embarcados;
• Subversion;
• Autotools;

Local:
Universidade de São Paulo – Campus Cidade Universitária

Os interessados podem encaminhar seus currículos para:
Hilel Becher <hilel@lsi.usp.br>

Laboratório de Sistemas Integráveis Tecnológico
Laboratório de Sistemas Integráveis

O código fonte pode ser encontrado neste link.

O programa de exemplo será um cronômetro que vai utilizar a classe QTimer, uma das principais classes do QT, e vai mostrar o tempo utilizando um display estilo LCD de calculadora com a classe QLCDNumber.

QT e os Timers

O suporte mais básico a timers no QT é disponibilizado pela classe QObject, que fornece os métodos QObject::startTimer() e QObject::killTimer(). O primeiro método retorna um ID único de timer e o segundo finaliza o timer através desse ID.

Para que isso funcione, no entanto, o trecho de código que utiliza esse mecanismo precisa estar dentro de um “event loop”. A partir do momento que o timer for iniciado ele de tempos em tempos (timeout) faz com que a aplicação dispate um QTimerEvent, que interrompe o fluxo normal do programa até que o evento seja processado.

O tempo máximo de timeout não é delimitado, sendo possível criar timers com timeout de anos, porém, o tempo mínimo pode variar de sistema para sistema. No windows Vista o timer mínimo é de 10 ms enquanto no Linux 2.6.x isso é configurável (o default é 4 ms). O QT vai tentar entregar todos os eventos, conforme pedidos, mas caso o sistema não permita ele vai descartar os “excedentes”.

Timers também podem ser utilizados em threads, porém deve-se respeitar a condição de estar dentro de um event loop. Threads merecem um artigo à parte, como sempre…

A classe QTimer implementa timers de mais alto nível, possibilitando algumas funcionalidades. Uma delas é o QTimer::singleShot(), que dispara um evento uma única vez.

Leia a extensa e repetitiva documentação, é chato, mas acredite, vai te poupar de muita QDorDeCabeca…

Mais sobre Sinais e Slots

Sinais e slots são utilizados para comunicação entre objetos, sendo uma das peças fundamentais do QT. Nesse sistema ao invés de se implementar callbacks para tratar eventos, utiliza-se o conceito de conectar sinais a slots, tornando a programação mais intuitiva.

Os sinais e slots são métodos de classe que são tratados pelo Meta-Object Compiler (moc) antes do código fonte ser compilado. Eles têm declarações especiais que não são parte do padrão C++, por isso o moc fazum parsing e gera o código fonte compilável.

Ao executar o comando moc sobre qualquer classe que implemente sinais e slots, uma certa quantidade de código fonte é gerada. Com o uso do programa qmake, a chamada ao programa moc fica a cargo do Makefile, tornando-a transparente para o programador.

Para que uma classe possa implementar sinais e slots, ela precisa ter acesso ao Meta-Object System. Por isso ela deve herdar da classe QObject ou suas subclasses, e precisa ter a macro Q_OBJECT na sua área de declaração privada. Terminados os preparativos, sinais são declarados em uma seção “signals:” e slots em seções “[public|protected|private] slots:“.

Um slot, depois de declarado, é então definido como qualquer outro método comum, podendo ser explicitamente chamado como qualquer outro. Já os sinais, são um pouco mais delicados, e são apenas declarados e jamais definidos pelo programador. A razão? Esta mensagem no final da tentativa de compilação:

tmp/moc_mydisplay.o: In function `MyDisplay::signalPlay()':
~/stopwatch/tmp/moc_mydisplay.cpp:89: multiple definition of `MyDisplay::signalPlay()'
tmp/mydisplay.o:~/stopwatch/mydisplay.cpp:169: first defined here
collect2: ld returned 1 exit status
make: ** [stopwatch] Erro 1

Dentro do arquivo moc_mydisplay.cpp é gerado o seguinte código:

// SIGNAL 0
void MyDisplay::signalPlay()
{
    QMetaObject::activate(this, &staticMetaObject, 0, 0);
}

Sim, o moc gera a definição dos sinais com chamadas a meta-métodos do QT. Portanto, definir o corpo de um sinal é ilegal no QT e vai gerar um erro de compilação por redefinição de método. Deixe que o moc cuida da implementação do sinal pra você.

Conecte-se

Não adianta apenas definir sinais e slots. É preciso definir como eles vão interagir. A maneira de fazer isso é conectando-os através do método connect() presente em todo herdeiro de QObject. Isso fará o moc implementar o sinal de forma que uma chamada a ele resulte numa chamada ao(s) slot(s) conectado(s), com os mesmos parâmetros.

Dependendo da forma de conexão, um sinal pode até retornar o mesmo valor que o último slot chamado retornar. Note que isso não é muito seguro para sinais conectados a vários slots, pois, nada garante a ordem de chamada.

Um dado sinal pode ser conectado a um segundo sinal diretamente. Um emit() no primeiro sinal é então equivalente a um emit() no segundo sinal, visto que após a etapa de criação dos mocs, a chamada ao primeiro resulta na chamada ao segundo, que resulta na chamada de outro método conectado e assim sucessivamente.

Formas de conexão

Existem basicamente três formas de conectar sinais e slots e se não usadas adequadamente podem ser fonte de bugs terrivelmente difíceis de se descobrir. Essas formas de conexão são passadas como parâmetros extras para o método connect(). São elas:

Conexão Direta: O slot é chamado imediatamente ao sinal ter sido emitido, na thread onde o sinal foi emitido. Isso funciona como uma chamada direta ao slot.

Conexão Enfileirada: O sinal é emitido e a chamada ao slot vai para uma lista interna do QT, e o sinal retorna imediatamente, independentemente do slot ter sido chamado ou não. O evente loop vai então processando essa lista e só mais tarde o slot será invocado na thread onde o objeto do slot reside.

Conexão Automática: Este é o tipo default, utilizado quando não se especifica o tipo de conexão. É uma das “Sementes do Mal”, pois apresenta dois comportamentos distintos: se o sinal e o slot residirem em uma mesma thread, funciona como conexão direta, mas caso contrário, funciona como conexão enfileirada.

Conexão enfileirada Bloqueante: Ué!? não eram só três? Well, essa é uma das vantagens de ler esse artigo: te salva de documentação inconsitente! Essa conexão é semelhante à conexão enfileirada, exceto pelo fato de que a thread do sinal fica bloqueada até o sinal ser devidamente executado. Note que só deve se utilizada com muito cuidado, e para sinais e slots em threads diferentes. O mal uso disso poderá causar deadlocks. Você vai saber quando vir algo assim:

user@host:~/stopwatch$ ./stopwatch
Qt: Dead lock detected while activating a BlockingQueuedConnection: Sender is
QPushButton(0x807e2d8), receiver is MyDisplay(0x8076ac0)

Para sanar as dúvidas a respeito do que significa a expressão “thread onde um objeto reside” consulte a documentação do QT arespeito de threads.

Tome sempre muito cuidado com sinais, slots, timers e threads. Esses são recursos fundamentais do QT, mas o seu mal uso pode acarretar em bugs extremamente difíceis de serem localizados. Consulte toda a documentação à respeito.

Descendo à fonte

O nosso exemplo se compões de duas classes MyDisplay e StopWatch e um arquivo main comum. O main apenas cria uma QApplication e um objeto StopWatch. A classe MyDisplay cuida da parte visual do programa, consistindo em um diálogo com botões e um display no estilo LCD. A classe StopWatch vai criar um widget de display e implementar o timer. Note que essa arquitetura não é a mais elegente, sendo mais interessante fazer a classe StopWatch herdar de MyDisplay. Porém, isso estragaria a brincadeira praticamente eliminando a necessidade do uso de sinais e slots.

O uso de sinais e slots fica mais claro quando queremos que objetos se comuniquem com o seu exterior. Em geral, as classes não conhecem o que há fora delas. Passar ponteiros de objetos externos para dentro delas, fere o encapsulamento e torna o código menos genérico. Em nosso exemplo, o uso mais interessante para sinais e slots é para o objeto myDisplay (interno a StopWatch) comunicar eventos de/para o objeto stopwatch (externo a Mydisplay), sem que para isso se perca em generalidade ou encapsulamento.

Com a ajuda do QT Designer (num outro artigo eu falarei dele), criei o diálogo, botões e LCD. Depois simplifiquei o código para se adequar aos nossos propósitos. Como myDisplay herda de QDialog e este herda indiretamente de QObject, para usarmos sinais e slots bastou acrescentar a macro Q_OBJECT na seção privada da declaração da classe. Após isso, acrescentei entre outros auxiliares, os métodos:

public slots:
    void slotDisplayValue( long );
 
private slots:
    void slotPlay();
    void slotStop();
 
signals:
    void signalPlay();
    void signalPause();
    void signalStop();
    void signalReset();

Os sinais comunicarão ao exterior os eventos relacionados aos cliques nos botões. Já os slots privados farão um pré-processamento interno, enquanto o público receberá o valor de ticks vindo do timer externo. Dessa forma a classe envia informações ao exterior e recebe informações de fora, sem conhecer o que está do outro lado. A boa e velha interface por contrato.

public slots:
    void slotPlay();
    void slotPause();
    void slotStop();
    void slotReset();
 
private slots:
    void slotTick();
 
signals:
    void signalTicks( long );

Análoga e inversamente a classe StopWatch implementa os slots que receberão os sinais da classe MyDisplay, e declara o sinal que enviará informações para o seu slot público.

Ela também implementa um QTimer que vai disparar a cada 10 milissegundos (para que os nosso amigos lerdinhos do Vista possam acompanhar!), incrementando um contador. Esse contador é enviado de volta ao display que o formata e exibe.

O cronômetro pode ser parado, pausado e reiniciado a qualquer momento, clicando nos botões correspondentes.

Os Finalmentes

O exemplo em si não tem muito código, mas ilustra o uso mais básico de timers e a construção de sinais e slots customizados. Uma atenção toda especial, no entanto, deve ser dada aos detalhes que envolvem o uso desses recursos, pois eles podem se tornar armadilhas letais.

Links importantes

Sinais e Slots
QTimer
Threads no QT
Documentação on-line do QT