Infelizmente em nenhuma das duas palestras práticas (minha e do Fernando) houve participação interativa, e ninguém que eu saiba abriu meu pacote-surpresa com os dumps a serem analisados. De qualquer forma, minha palestra ficou bagunçada pelo excesso de conteúdo e falta de tempo, o que me fez dar boas risadas ao ouvir no twitter que minha palestra foi mais um brainstorm. A intenção não era essa, claro, mas meu claro despreparo para muito conteúdo gerou essa impressão. Espero que do pouco que consegui explicar alguém tenha achado utilidade.

E, pelo jeito, futuramente irei aplicar essa mesma metodologia brainstorm em um videocast, que ainda não decidi como irei preparar. A ideia é analisarmos alguns dumps em conjunto e, para os que acompanharem online, a interatividade de perguntas & respostas.

Mas enquanto isso não acontece vamos dar uma olhada no que tínhamos no pacote-surpresa.

1. NotMyFaultEither.exe.mdmp - Stack Trash

0:000> kv
ChildEBP RetAddr  Args to Child
0012b200 7c90df3c 7c8025db 000000e8 00000000 ntdll!KiFastSystemCallRet
0012b204 7c8025db 000000e8 00000000 0012b238 ntdll!NtWaitForSingleObject+0xc
0012b268 7c802542 000000e8 000493e0 00000000 kernel32!WaitForSingleObjectEx+0xa8
0012b27c 6998ada6 000000e8 000493e0 003a0043 kernel32!WaitForSingleObject+0x12
0012bd70 6998aff1 000000c4 00000568 000000d0 faultrep!InternalGenerateMinidumpEx+0x335
0012bd9c 6998b50a 000000c4 00000568 0012c698 faultrep!InternalGenerateMinidump+0x75
0012c678 69986652 000000c4 00000568 0012c698 faultrep!InternalGenFullAndTriageMinidumps+0x8a
0012dea0 69987d3d 0012df18 0015c300 00000000 faultrep!ReportFaultDWM+0x4e5
0012e398 699882d8 0040a1dc 0012f1e0 ffffffff faultrep!StartManifestReportImmediate+0x268
0012f404 7c8643c6 0040a1dc ffffffff 0012fc24 faultrep!ReportFault+0x55a
Unable to load image C:\Documents and Settings\Administrador\Desktop\NotMyFaultEither.exe
*** WARNING: Unable to verify timestamp for NotMyFaultEither.exe
*** ERROR: Module load completed but symbols could not be loaded for NotMyFaultEither.exe
0012f678 004018aa 0040a1dc e280eec4 1d7f113b kernel32!UnhandledExceptionFilter+0x55b
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f9ac 00401357 dededede dededede dededede NotMyFaultEither+0x18aa
0012fbe8 dededede dededede dededede dededede NotMyFaultEither+0x1357
0012fbec dededede dededede dededede dededede 0xdededede
0012fbf4 dededede dededede dededede dededede 0xdededede
...

Como foi visto na palestra, uma pilha nesse estado demonstra claramente alguma variável que estourou e corrompeu o resto da pilha de chamadas. Na hora de voltar para a função chamadora, o endereço usado foi o endereço reescrito por lixo, e daí temos o "crash-pattern" Stack Trash.

2. NotMyFaultEither.mdmp - Dead Lock

0:000> kv
ChildEBP RetAddr  Args to Child
0012f900 7c90df3c 7c8025db 0000007c 00000000 ntdll!KiFastSystemCallRet
0012f904 7c8025db 0000007c 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
0012f968 7c802542 0000007c ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xa8
0012f97c 00401176 0000007c ffffffff 00000111 kernel32!WaitForSingleObject+0x12
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f9c0 7c910202 00000002 001506e8 00150000 NotMyFaultEither+0x1176
0012f9f8 7e3746d3 01010050 00000000 00000000 ntdll!RtlpAllocateFromHeapLookaside+0x42
0012fa5c 7e382672 01010050 01100068 7e3a4716 user32!DrawStateW+0x5cd
0012fae8 7e382c75 001563ac 01010050 00000003 user32!xxxBNDrawText+0x313
0012fb20 002d0036 00000000 00000020 0012fb3c user32!xxxDrawButton+0xbb
0012fb30 7e3799d8 0000800a 0012fbc8 7e375ba2 0x2d0036
0012fb3c 7e375ba2 0000800a 002d0036 fffffffc user32!NotifyWinEvent+0xd
0012fbc8 00000000 002d0036 004011b0 dcbaabcd user32!ButtonWndProcWorker+0x79b
0:000> !handle 0000007c
Handle 0000007c
  Type         	Thread
0:000> ~* kv

.  0  Id: 5e4.39c Suspend: 0 Teb: 7ffdd000 Unfrozen
ChildEBP RetAddr  Args to Child
0012f900 7c90df3c 7c8025db 0000007c 00000000 ntdll!KiFastSystemCallRet
0012f904 7c8025db 0000007c 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
0012f968 7c802542 0000007c ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xa8
0012f97c 00401176 0000007c ffffffff 00000111 kernel32!WaitForSingleObject+0x12
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f9c0 7c910202 00000002 001506e8 00150000 NotMyFaultEither+0x1176
0012f9f8 7e3746d3 01010050 00000000 00000000 ntdll!RtlpAllocateFromHeapLookaside+0x42
0012fa5c 7e382672 01010050 01100068 7e3a4716 user32!DrawStateW+0x5cd
0012fae8 7e382c75 001563ac 01010050 00000003 user32!xxxBNDrawText+0x313
0012fb20 002d0036 00000000 00000020 0012fb3c user32!xxxDrawButton+0xbb
0012fb30 7e3799d8 0000800a 0012fbc8 7e375ba2 0x2d0036
0012fb3c 7e375ba2 0000800a 002d0036 fffffffc user32!NotifyWinEvent+0xd
0012fbc8 00000000 002d0036 004011b0 dcbaabcd user32!ButtonWndProcWorker+0x79b

   1  Id: 5e4.6a4 Suspend: 0 Teb: 7ffdc000 Unfrozen
ChildEBP RetAddr  Args to Child
00b8ff10 7c90df3c 7c91b22b 00000080 00000000 ntdll!KiFastSystemCallRet
00b8ff14 7c91b22b 00000080 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
00b8ff9c 7c901046 0040e940 004010e0 0040e940 ntdll!RtlpWaitForCriticalSection+0x132
00b8ffa4 004010e0 0040e940 00000000 00000000 ntdll!RtlEnterCriticalSection+0x46
WARNING: Stack unwind information not available. Following frames may be wrong.
00b8ffec 00000000 004010c0 0012f99c 00000000 NotMyFaultEither+0x10e0
0:000> !cs 0040e940
-----------------------------------------
Critical section   = 0x0040e940 (NotMyFaultEither+0xE940)
DebugInfo          = 0x00154498
LOCKED
LockCount          = 0x1
OwningThread       = 0x0000039c
RecursionCount     = 0x1
LockSemaphore      = 0x80
SpinCount          = 0x00000000

A thread ativa no momento do dump aguardava por outra thread. Listando todas as threads do processo temos a primeira e a segunda, que tenta entrar em um critical section. Quando vemos que aquele CS estava sendo bloqueado pela primeira thread vemos claramente se tratar de um dead lock.

3. NotMyFaultEither_100808_172407.dmp - Access Violation

0:000> kv
ChildEBP RetAddr  Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f9cc 7e37f916 01010052 005a0049 0012f9f4 NotMyFaultEither+0x10a3
0012fa58 7e37f991 01010052 00000043 01100076 user32!ClientFrame+0xe0
0012fa7c 7e382909 01010052 0012fa98 00000000 user32!DrawFocusRect+0x40
0012fae8 7e382c75 00156304 01010052 00000003 user32!xxxBNDrawText+0x3e9
0012fb20 001100a0 00000000 00000020 0012fb3c user32!xxxDrawButton+0xbb
0012fb30 7e3799d8 0000800a 0012fbc8 7e375ba2 0x1100a0
0012fb3c 7e375ba2 0000800a 001100a0 fffffffc user32!NotifyWinEvent+0xd
0012fbc8 00000000 001100a0 004010f0 dcbaabcd user32!ButtonWndProcWorker+0x79b
0:000> ? eax+edx
Evaluate expression: 0 = 00000000
0:000> u
NotMyFaultEither+0x10a3:
004010a3 66890c02        mov     word ptr [edx+eax],cx
004010a7 83c002          add     eax,2
004010aa 6685c9          test    cx,cx

O disassemble da instrução inválida tenta escrever claramente em cima do endereço zerado (edx + eax). Dessa forma fica fácil saber que esse tipo de escrita não é permitido, constituindo nosso famosíssimo AV.

4. NotMyFaultEither_100808_175404.dmp - Exception not Handled

eax=00000000 ebx=00000111 ecx=7c91003d edx=00010000 esi=00330120 edi=7e374dfa
eip=7c90120e esp=0012f9a0 ebp=00000001 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!DbgBreakPoint:
7c90120e cc              int     3
0:000> kv
ChildEBP RetAddr  Args to Child
0012f99c 004011ec 0012fc24 004010d0 0012fbe8 ntdll!DbgBreakPoint (FPO: [0,0,0])
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f9cc 7e37f916 01010054 005a0049 0012f9f4 NotMyFaultEither+0x11ec
0012fa58 7e37f991 01010054 00000043 01100076 user32!ClientFrame+0xe0

Esse foi meio de brinde. Uma exceção de breakpoint (int 3, ntdll!DbgBreakPoint) lançada sem um depurador atachado implica em derrubamento do processo, pois é uma exceção como outra qualquer. O programador deve ter esquecido um DebugBreak ou algo que o valha no código de produção, que acabou sendo executado.

5. ntdll_cliente.dll - Importação de símbolos

Essa foi a DLL encontrada no cliente quando ocorreu o problema relatado na imagem, também em anexo. Isso foi demonstrado na palestra com a ajuda do meu script que carrega DLLs, além de um pouco de sorte. Podemos analisar esse caso com mais calma em outro artigo. Acho que já falei demais por aqui.

Mas nem por isso deixei de terminar uma primeira versão do aplicativo que irei usar como base na minha palestra do nosso próximo encontro C++: Crash Dump Analysis. Se alguém tiver dicas de quais os problemas mais difíceis do Universo para analisar em um dump de memória, comente a respeito e veremos o que dá pra fazer.

Enquanto isso, continuo descobrindo maravilhas do WinDbg. Essa semana fiquei brincando de colocar breakpoint em user-mode, mas depurando o kernel, como fizeram os rapazes do Ntdebugging. A conclusão é que ele vale para todos os aplicativos abertos. Tente com o MessageBox!

!process 0 0 notepad.exe
.reload /user
bp user32!MessageBoxW

Mas devaneio. Talvez outra boa qualidade de um bom programador.

Padrão C++ (ISO/IEC 14882:1998)

cv-qualifier
 const
 volatile

Qualificadores de tipo

Chamamos de qualificador de tipo as palavrinhas mágicas const e volatile. Na prática elas definem como uma determinada variável será usada e se comportará durante a vida do programa.

Const

Uma variável const não pode ser alterada pelo programa durante sua execução, apenas durante sua inicialização:

const float pi = 3.14; // até onde sabemos, pi não irá mudar neste Universo

No exemplo acima, o valor de pi não pode mais ser alterado. Só que repare que ele foi, em determinado momento, alterado com um valor constante: na sua inicialização. Isso quer dizer que:

• pi é uma variável no programa representada por um local na memória endereçável pelo programa
• pi não é um define do pré-processador que irá virar uma constante literal (3.14, por exemplo)

// eu posso endereçar uma constante,
// desde que qualifique corretamente meu ponteiro
const float* ppi = & pi;

Teoricamente a região da memória que contiver uma variável const pode ser qualificada pelo sistema operacional como somente-leitura, mas isso não é uma obrigação. É obrigação do compilador avisar sobre tentativas de alteração da variável no meio do programa, mas nem sempre é possível enxergar que a memória não é alterável. Dessa forma, resultados imprevisíveis podem ocorrer.

Uso prático

Eu costumo usar variáveis const no lugar de defines. Além de ganhar na tipagem as constantes não precisam ser necessariamente globais, nem acessíveis por outros módulos. Um outro uso muito comum é criar variáveis locais que você sabe que não devem ser alteráveis por ninguém, como o tamanho de matrizes primitivas.

namespace Math
{
	const float Pi = 3.14;
}
 
//...
 
int func1(int x)
{
	float calc = x * Math::Pi;
	return calc;
}
 
//...
 
int func2(int y)
{
	const size_t PathSize = MAX_PATH * 2;
	//...
	//...
	char path[PathSize];
	//...
}

Volatile

O significado do volatile teoricamente muda de implementação para implementação, mas na prática é uma forma de definir uma variável que está sendo acessada por outros programas/threads/entidades espíritas que podem alterar o seu valor sem seu programa notar quando.

O exemplo clássico da API Win32 é o InterlockedIncrement, que realiza operações atômicas em valores inteiros. Para fazer isso é necessário usar um recurso interno disponível pelo processador que irá modificar a memória sem intrusão de outras threads/processadores.

Uso prático

Variáveis volatile geralmente interagem de alguma forma com o sistema em que rodam, e são representadas por ponteiros para memória retornada por esse sistema ou documentada como sendo de uso específico.

Const e Volatile

É possível que exista uma variável que não pode ser modificada pelo seu programa, mas é modificada pelo sistema, de forma que ela é uma mutante!

/// endereça o relógio do sistema, atualizado a cada 1/100 milissegundos
const volatile int* g_systemClock = (const volatile int*) 0x7689B9D4;

A definição de *g_systemClock é de uma memória que não pode ser alterada; só que ela é, pelo sistema. Então a variável também é volatile. No entanto, independente de ser const ou volatile, o tipo nunca será alterado, apenas qualificado. São duas coisas diferentes na linguagem.

Padrão C++ (ISO/IEC 14882:1998)

type-specifier
 enum-specifier

enum-specifier
 enum

Uma enumeração faz duas coisas: define um novo tipo, parecido com um inteiro, e cria uma lista de constantes com nomes significativos. A definição técnica do tipo de um enum é mais complicada, mas basicamente ele é um novo int.

Como funciona: definimos uma lista com cada elemento tendo um valor inteiro, geralmente único. Todos os nomes usados na lista passam a fazer parte do espaço de nomes atual e funcionam como constantes com o seu valor definido no início.

enum FileType // criamos o novo tipo inteiro FileType
{
   Binary = 1, // Binary é uma constante com valor igual a 1
   Text = 2, // Text é uma constante com seu sizeof igual a sizeof(FileType)
   Mixed = 3 // Todas as constantes da enumeração são do mesmo tipo
};

Obs.: Os elementos que não possuem valor definido são definidos automaticamente como o valor do elemento anterior acrescidos de um. Se for o primeiro elemento, seu valor padrão é zero.

enum Numbers
{
   zero,  // igual a zero
   one,   // igual a um
   two,   // igual a dois
   three  // igual a tres
};
 
 
enum Hexa
{
   JulioCesar = 1,
   Lucio = 3,
   Juan,                // Juan = 3 + 1 = 4
   Gilberto Silva = 6,
   Felipe Melo          // 6 + 1 = 7
};

enum VirgulaSafada { 
   um = 1, 
   dois, 
   tres, // o que essa vírgula no final tá fazendo aqui?
};

Uso prático

Geralmente usamos enumerações para definir valores únicos (tag) em um argumento de função, ou, mais moderno, como substituto daqueles antigos defines em C para mapas de bits. Nesse último caso não usamos o tipo da enumeração, pois ele pode conter apenas um valor único definido, e não um conjunto deles:

enum ModoDeServir
{
   assado,
   cozido,
   frito,
   cru
};
 
 
void Cook(Prato p, ModoDeServir ms);
 
main()
{
   Cook(frango, cozido);
}
 
 
enum FileOpenMode
{
   fomRead   = 0x0001,
   fomWrite  = 0x0002,
   fomOver   = 0x0004,
   fomDel    = 0x0008,
};
 
void OpenFile(DWORD fileOpenMode);
 
main()
{
   OpenFile(fomRead | fomWrite);
}

Note que usamos uma enumeração nesse último caso para termos um nome significativo para uma flag, além desse nome fazer de fato parte dos nomes do programa, e não um define que, para o compilador, não existe.

Boas práticas

Como os tipos da enumeração passam a pertencer ao namespace atual, eles podem se misturar facilmente com todos os nomes daquele namespace. Dessa forma, é útil e bem organizado definir um prefixo para os nomes, que pode ser formado pelas iniciais do nome da enumeração, como no exemplo acima (fom = FileOpenMode).

O surgimento do enum veio como evolução de uma prática já consagrada pelo uso na linguagem C, que eram as listas de valores constantes criados através de defines com algum prefixo em comum (FILE_SHARE_*, SW_SHOW_*, etc). Portanto, sempre que se encontrar em uma situação para criar esse tipo de lista, a enumeração é o caminho atualmente ideal.

// A listagem abaixo pode virar um enum...
#define FOM_READ   0x0001
#define FOM_WRITE  0x0002
#define FOM_OVER   0x0004
#define FOM_DEL    0x0008
 
// ... como este aqui!
enum FileOpenMode
{
   FOM_READ   = 0x0001,
   FOM_WRITE  = 0x0002,
   FOM_OVER   = 0x0004,
   FOM_DEL    = 0x0008,
};
 
 
// esse pedaço de código abaixo...
int main()
{
   OpenFile(path, FOM_WRITE);
}
 
// ... vira isso após ser pré-processado...
int main()
{
   OpenFile(path, 0x0002);
}
 
// ... mas isso se fossem usados enums...
int main()
{
   OpenFile(path, FOM_WRITE); // FOM_WRITE faz parte da linguagem
}

Atualização: e qual a diferença?

Perguntado por um leitor sobre qual a diferença prática do último exemplo, onde temos praticamente o mesmo resultado entre usar defines e enumerações, imaginei que a mesma dúvida pode ter surgido para várias pessoas, porque é uma boa dúvida. Dá a entender que o autor deste artigo está se atentando a preciosismos da linguagem (e está mesmo!), mas à vezes as aparências enganam.

Para ilustrar melhor fiz um mais elaborado. Aqui, estamos lendo pedaços de dados que tiveram que ser alinhados com alguma "gordura".

// alinhamento obrigatório pelo leiaute dos dados
#define CHUNKSZ_BASE 0x5000
 
#define CHUNKSZ_TINY   0x1000 + CHUNKSZ_BASE
#define CHUNKSZ_SMALL  0x2000 + CHUNKSZ_BASE
#define CHUNKSZ_MEDIUM 0x4000 + CHUNKSZ_BASE
#define CHUNKSZ_HUGE   0x8000 + CHUNKSZ_BASE
 
 
// alinhamento obrigatório pelo leiaute dos dados
static const int chunkSizeBase = 0x5000;
 
enum ChunkSize
{
   chunkszTiny   = 0x1000 + chunkSizeBase,
   chunkszSmall  = 0x2000 + chunkSizeBase,
   chunkszMedium = 0x4000 + chunkSizeBase,
   chunkszHuge   = 0x8000 + chunkSizeBase,
};
 
 
// Fonte original
int main()
{
	// lendo quadro pedaços de dados (tamanho médio)
   ReadChunkFromFile(file, CHUNKSZ_MEDIUM * 4);
 
	// lendo quadro pedaços de dados (tamanho médio)
   ReadChunkFromFile(file, chunkszMedium * 4);
}
 
 
// Pós-processado
int main()
{
	// lendo sei lá o que (perde alinhamento)
   ReadChunkFromFile(file, 0x4000 + CHUNKSZ_BASE * 4);
 
	// lendo quadro pedaços de dados (tamanho médio)
   ReadChunkFromFile(file, chunkszMedium * 4);
}
 

Aviso para os programadores mais calejados, eu omiti propositalmente os parênteses obrigatórios para qualquer define que tenha cálculos matemáticos, para ilustrar que muitas vezes o que vemos antes não é o que aparece depois.

Uma coisa de cada vez: existem modificadores (ou qualificadores) de tipo e especificadores de tipo. Volatile e extern se encaixam na primeira categoria, enum e union na segunda. Veremos um pouco desses dois lados da linguagem em doses paliativas.

Padrão C (ISO/IEC 9899:1990)

6.5.2.2 enum-specifier
 enum

6.5.3 type-qualifier
 const
 volatile

6.5.2.1 struct-or-union
 struct
 union

6.5.1 storage-class-specifier
 typedef
 extern
 static
 auto
 register

Padrão C++ (ISO/IEC 14882:1998)

type-specifier
 enum-specifier

enum-specifier
 enum

cv-qualifier
 const
 volatile

class-key
 class
 struct
 union

storage-class-specifier
 auto
 register
 static
 extern
 mutable

decl-specifier
 storage-class-specifier
 typedef

Modificadores de tipo

Um modificador de tipo é opcional na definição de um tipo e deve estar sempre relacionado com a declaração de alguma variável. Ele determina, em termos gerais, qual será a função dessa variável. Ela pode ser modificada? Onde ela se encontra no programa? Como ela será modificada?

Como exemplo rápido, temos abaixo uma variável que é atualizada pelo clock do processador e uma variável que não pode ser alterada após sua primeira atribuição:

volatile int* clockSecs = <algum-endereço-do-sistema>;

const float pi = 3.14;

Fica meio óbvio que a primeira variável possui seu valor volátil, ou seja, muda conforme o tempo passa, e não depende do próprio código (pode mudar sem sua permissão). A segunda variável também tem um uso explícito, uma vez que o valor de pi nunca será alterado (não nesse Universo).

Especificadores de tipo

Os especificadores de tipo possuem cada um sua peculiaridade. Os mais peculiares, que veremos nos próximos artigos, serão as enumerações e as construções bizarras de structs e unions.

enum Contador { um = 1, dois, tres, };

union Atoms { struct { int part1; int part2; } parts; int64 total; };

Aqui não é um compêndio teórico sobre a linguagem. Vamos falar particularmente da programação Windows, mas esteja livre para dar seus pitacos com respeito a outros sistemas operacionais e suas implementações igualmente exdrúxulas =)

Já foi escrito muita coisa sobre os prós e contras da notação húngara. Já o typedef arcaico, esse pedacinho imprestável de código, ficou esquecido, e hoje em dia traz mais dúvidas na cabeça dos principiantes em C++ do que deveria. Para tentar desobscurecer os mitos e fatos, vamos tentar explicar o que significa essa construção tão atípica, mas comum no dia-a-dia.

Vejamos um exemplo típico desse pequeno Frankenstein semântico:

typedef struct _MINHASTRUCT {
   int x;
   int y;
}
MINHASTRUCT, *LPMINHASTRUCT;

Bom, eu nem sei por onde começar. Talvez pelo conceito de typedef.

Typedefs

Um typedef, basicamente, é um apelido. Você informa um tipo e define "outro tipo".

typedef <tipo> apelido;

O <tipo> é tudo que fica entre o typedef e o novo nome, que deve ser um identificador válido na linguagem. Por exemplo, a empresa onde trabalho fez um typedef informal do meu nome:

typedef Wanderley Caloni Wandeco;

Se, futuramente, eu sair da empresa e entrar outro "Wanderley alguma-coisa", será possível usar o apelido novamente, bastando alterar o typedef:

typedef Wanderley Cardoso Wandeco;

Bom, "outro tipo" é forma de dizer. Isso é uma descrição errônea em muitos livros. De fato, o compilador enxerga o mesmo tipo com outro nome, daí chamarmos o typedef de apelido, mesmo.

/** @file dois_apelidos.cpp */
#include <iostream>
 
using namespace std;
 
struct Struct
{
   int x;
   int y;
};
 
typedef Struct Struct1;
typedef Struct Struct2;
 
int main()
{
   Struct1 s1;
   Struct2 s2;
 
   cout << typeid(s1).name() << endl;
   cout << typeid(s2).name() << endl;
}

C:\Tests>cl /EHsc dois_apelidos.cpp
...
/out:dois_apelidos.exe
dois_apelidos.obj

C:\Tests>dois_apelidos.exe
struct Struct
struct Struct

Granularidade dos tipos

Tipos simples são fáceis de entender porque possuem seus símbolos no mesmo lugar:

int x;
char c;
long p;

Já os tipos um pouco mais complicados permite alguma mudança aqui e acolá:

int* x;
char *y;
long * p;

Essa liberdade da linguagem, mesmo sendo um recurso útil, pode ser bem nocivo dependendo de quem olha o código:

int x, y; // dois inteiros
int * x, y; // um ponteiro para inteiro e um inteiro
int x, *y; // um inteiro e um ponteiro para inteiro
int *x, y; // um ponteiro para inteiro e um inteiro

Em algumas formas da sintaxe, além de ser inevitável, gera bastante desconfiança:

// Um ponteiro para função que recebe dois inteiros e não retorna nada.
typedef void (*FP)(int, int);

// Um ponteiro para função que recebe dois inteiros e não retorna nada.
void (*)(int, int);

// Um cast para ponteiro para função que recebe dois inteiros e não retorna nada.
( ( void (*)(int, int) ) pf )(x, y);

#include <iostream>
 
void func(int x, int y)
{
   std::cout << x << '-' << y << '\n';
}
 
int main()
{
   void* pf = func;
   ( ( void (*)(int, int) ) pf )(3, 14);
}

Structs em C++

Antigamente, as structs eram construções em C que definiam um agregado de tipos primitivos (ou outras structs) e que poderiam gerar variáveis desse tipo em qualquer lugar, desde que informado seu nome e que se tratasse de uma struct:

/** @file structs.cpp */
struct MyStruct { int x, y; };
 
void func1()
{
   struct MyStruct ms;
   //...
}
 
void func2(struct MyStruct msa)
{
   //...
}
 
int main()
{
   struct MyStruct ms;
   func2(ms);
}

Para evitar toda essa digitação, os programadores usavam um pequeno truque criando um apelido para a estrutura, e usavam o apelido no lugar da struct (apesar de ambas representarem a mesma coisa).

struct MyStruct { int x, y; };
typedef struct MyStruct MS;

ou

typedef struct MyStruct { int x, y; } MS;
struct MyStruct ms1; // ainda prolixo
MS ms2; // mais simples

Com a definição da linguagem C++ padrão, e mais moderna, essa antiguidade foi removida, apesar de ainda suportada. Era possível usar apenas o nome do struct como seu tipo:

/** @file structs.cpp */
struct MyStruct { int x, y; };
 
void func1()
{
   /*struct*/ MyStruct ms;
   //...
}
 
void func2(/*struct*/ MyStruct msa)
{
   //...
}
 
int main()
{
   /*struct*/ MyStruct ms;
   func2(ms);
}

Porém, isso vai um pouco além de quando a Microsoft começou a fazer código para seu sistema operacional. Naquela época, o padrão ainda estava se formando e existia mais ou menos um consenso de como seria a linguagem C++ (sem muitas alterações do que de fato a linguagem C já era). De qualquer forma, a linguagem C imperava bem mais que C++. Dessa forma, já era bem formada a ideia de como declarar uma struct: a forma antiga.

typedef struct _MINHASTRUCT {
   int x;
   int y;
}
MINHASTRUCT, *LPMINHASTRUCT;

Além do uso controverso do _sublinhado para nomear entidades (que no padrão foi recomendado que se reservasse aos nomes internos da biblioteca-padrão) e do uso de MAÍUSCULAS_NO_NOME (historicamente atribuído a nomes definidos no pré-processador), o uso do typedef atracado a um struct era muito difundido. E ficou ainda mais depois que a API do Windows foi publicada com essas definições.

Como fazer,então?

Ora, do mesmo jeito que é feito há vinte anos: sem typedefs. O próprio paradigma da linguagem, independente de padrões de APIs, de sistemas operacionais ou de projetos específicos já orienta o programador para entender o que o espera na leitura de um código-fonte qualquer. Qualquer pessoa que aprendeu o básico do básico sobre ponteiros e structs consegue ler o código abaixo:

// Papai, o que que é isso?
// Ora, filho, apenas uma definição de estrutura!
//
struct MinhaStruct {
   int x;
   int y;
};
 
// muitas linhas abaixo...
 
void func(MinhaStruct* ms)
{
   // asterisco significa ponteiro para MinhaStruct!
}
 
int main()
{
   MinhaStruct ms;
   func(&ms);
}

Agora, para entender a forma antiga, ou você se baseou no copy&paste dos modelos Microsoftianos, ou seja, decoreba, ou você é PhD em Linguagem C/C++ e padrões históricos de linguagens legadas. Se não é, deveria começar o curso agora.

// Papai, o que que é isso?
// Ora, filho, apenas uma definição de sinônimo da struct
// _MINHASTRUCT, cujo nome não é usado, para dois nomes
// em maiúsculas, apesar se não serem defines, com uma
// nomenclatura de ponteiro que eu nunca vi na vida (obs: 
// papai programa em um sistema não-Windows).
//
typedef struct _MINHASTRUCT {
   int x;
   int y;
}
MINHASTRUCT, *LPMINHASTRUCT;
 
// muitas linhas abaixo...
 
void func(LPMINHASTRUCT ms)
{
   // o que diabos é um LP, mesmo?
}
 
int main()
{
   MINHASTRUCT ms;
   func(&ms);
}

Da mesma forma, o uso de uma estrutura simples de tipos mantém a lista de nomes do seu projeto limpa e clara. Compare o visualizador de classes em projetos Windows com algo mais C++ para ter uma ideia.

É claro, essa é apenas uma sugestão. Existem vantagens em sua utilização. Existe alguma vantagem no modo antigo? Existe: a Microsoft usa, e talvez mais pessoas usem. Basta a você decidir qual deve ser o melhor caminho.

Atualização

De acordo com o leitor  Adriano dos Santos Fernandes, a obrigatoriedade do nome struct após seu nome continua valendo para a linguagem C padrão, assim como no compilador GCC ocorre um erro ao tentar omiti-la. Apenas na linguagem C++ essa obrigatoriedade não existe mais.

Eu não fiz meus testes, mas confio no diagnóstico de nosso amigo. A maior falha do artigo, no entanto, é usar a linguagem C como base, quando na verdade ele deveria falar sobre o uso desses typedefs em C++. Esse erro também foi corrigido no original.

Em dois projetos usando Visual C++ 2008 e Borland C++ Builder 5 (última versão que funciona direito) eu fiz uma exportação da função soma em linguagem C (o fonte é um .c). Veja o resultado:

Já usando a linguagem C++ (o fonte é um .cpp) temos outro resultado totalmente diferente para nossas duas funções soma descritas no artigo anterior:

Se quiser tentar entender essas letrinhas bizarras, recomendo baixar projetos de exemplo. Se apenas entender que você não conseguirá juntar classes VC++ e Builder usando dllexport para tudo quanto é lado, então terminamos por aqui.

int soma(int x, int y);
double soma(double x, double y);
 
int main()
{
    int zi = soma(2, 3);
    double zd = soma(2.5, 3.4);
    return 0;
}
 

Imediatamente o compilador iria acusar os seguintes erros:

overload.c

overload.c(2) : warning C4028: formal parameter 1 different from declaration
overload.c(2) : warning C4028: formal parameter 2 different from declaration
overload.c(2) : error C2371: 'soma' : redefinition; different basic types
        overload.c(1) : see declaration of 'soma'

Isso acontece porque em C os identificadores são únicos por escopo. Esse é o motivo por que o seguinte código também está errado:

int main()
{
    int x = 0;
    int x = 1;
    return 0;
}
 
 

overload.c
overload.c(5) : error C2374: 'x' : redefinition; multiple initialization
        overload.c(4) : see declaration of 'x'

De volta aos anos 90, isso também está errado em C++. Até por uma questão de lógica: como o compilador pode saber a qual variável estamos nos referindo se usarmos o mesmo nome para duas delas?

Só que existe um truquezinho para impedir essa ambiguidade quando falamos de funções: os parâmetros que ela recebe.

int soma(int x, int y);
double soma(double x, double y);
 
int main()
{
    int zi = soma(2, 3); // dois tipos int: chamar soma(int, int)
    double zd = soma(2.5, 3.4); // dois tipos double: só pode ser soma(double, double)
    return 0;
}
 

C:\Tests>cl /c overload.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

overload.cpp

C:\Tests>

Isso permitiu que em C++ fosse criada a sobrecarga estática, que é exatamente isso: chamar a função não apenas de acordo com seu nome, mas também de acordo com sua assinatura, ou seja, o número e o tipo dos parâmetros recebidos. Chamamos de sobrecarga estática porque isso é feito apenas pelo compilador, não pesando em nada durante a execução do programa.

Entre seus usos mais comuns estão os seguintes:

• Ter funções com o mesmo nome mas que tratam de diferentes parâmetros;
  • soma(int, int);
  • soma(double, double);
  • Obs.: Isso ignora, é claro, as facilidades dos templates.
• Versões novas da mesma função que recebem parâmetros adicionais;
  • export_data(void* buffer, int size);
  • export_data(void* buffer, int size, unsigned long options);
• Mesmo nome de método para setar e obter o valor de uma propriedade;
  • Class::Property(int x); // setter
  • int x Class::Property() const; // getter
• Bom, o que mais sua imaginação mandar =)

No entanto, quando esses dados viram algo de útil em um determinado contexto, não necessariamente alterando-se seu conteúdo na memória, passamos a lidar com informação. Ou seja, é um dado com significado. E informação é a interpretação desses mesmos dados.

A conclusão óbvia para isso, falando de strings, é: uma série de bytes enfileirados na memória pode ser uma string.

Para tanto precisamos apenas de dados (os bytes enfileirados) e significado (uma tabela de símbolos que traduza esses bytes para caracteres e a definição de como a string se organiza).

Por exemplo, uma série de bytes diferentes de zero com valores que representam índices de uma tabela de tradução de caracteres e que termina sua sequência em um byte com o valor zero nele é considerada uma string C, ou string terminada em nulo.

Já uma mesma sequência de bytes no mesmo molde só que sem o byte final com o valor zero, mas com um byte inicial que tem como valor não um índice de caractere, mas o número de bytes subsequentes, isso é uma string Pascal, ou uma string com contador de tamanho.

Agora note por que tanto uma string vazia em Pascal e em C possuem os mesmos dados, mas informação diferente.

Outras strings que não necessariamente possuem terminador nulo: std::string, UNICODE_STRING, strings no kernel.

Esse artigo é só para constar em minha lista de referência para o aprendizado de C, C++ e todas as outras coisas que vem depois. Se eu tivesse que escrever isso lá no início, provavelmente recomendaria mais linques de livros e saites em inglês. Hoje, felizmente, temos um conteúdo em pleno desenvolvimento em nossa blogosfera tupiniquim. E espero que continue assim!

C/C++

• Strings
• Strings e Números
• Os diversos tipos de casting
• Pointeiros e Referências
• Templates
• Smart Pointer - Introdução
• Auto Pointer (auto_ptr)
• Boost Shared Pointer, Weak Pointer e Scoped Pointer
• Boost Shared Array e Scoped Array
• Quando usar cada um dos smart pointers
• As infinitas e riquíssimas discussões na lista C/C++

Visual Studio

• Como usar o Visual Studio
• Compilando o Boost no Windows (usando Visual Studio)

Mais assuntos?

A internet brasileira cresceu como um todo. Mesmo que você deseje saber mais sobre microprocessadores ou drivers para Windows, em português, hoje isso é possível. É claro que o que não é possível é você se dedicar profissionalmente a essas áreas sem saber inglês. Mas é uma muito bem-vinda manifestação das pessoas que fazem acontecer todas essas coisas em nosso país.