Planet C e C++ Brasil

Meus bugs fazem as pessoas perderem bastante dinheiro. Ainda bem.

2008-07-22T01:14:00+00:00

http://en.wikipedia.org/wiki/Therac-25

0 comentário(s)

Todos os fontes do meu site pelo Google Code

2008-07-15T01:38:36+00:00

Simplesmente muito legal mesmo:

Todos (quase todos) os fontes usados no blog
Outline do exemplo de WTL. Clique nos links dos includes e veja
omni_ptr, meu smart pointer COM mais esperto que o os outros

Putz!

0 comentário(s)

Win32: sincronização

2008-07-13T04:49:11+00:00

Em um post do passado eu falei sobre o maravilhoso mundo das threads e de todos problemas que as threads resolvem. Agora é a hora de começarmos a ver os inúmeros problemas que as threads criam. Pensou que ia ser fácil? Pois é, já começou errado...

Como um trecho de código vale mais que e = m * pow(c, 2);, vamos começar com um exemplo clássico de problema que acontece quando temos várias threads compartilhando um recurso:

 
 
#include "stdafx.h"
 
/*
conteúdo do stdafx:
 
#ifndef _WIN32_WINNT		
#define _WIN32_WINNT 0x0501
#endif						
 
#include <Windows.h>
 
#include <stdio.h>
#include <tchar.h>
 
#include <iostream>
#include <vector>
 
#include <assert.h>
#define ASSERT assert
*/
 
using std::cout;
using std::endl;
using std::vector;
 
//
// classe simples (e incompleta) que implementa uma lista
// duplamente ligada. Se você disse "hã?", leia o artigo
// sobre "Linked list" da wikipedia.
//
template<typename T>
class LinkedList
{
  struct NODE
  {
    NODE* previous;
    NODE* next;
    T data;
  };
 
  NODE rootNode_;
  unsigned int count_;
 
public:
 
  LinkedList()
  {
    count_ = 0;
    rootNode_.previous = rootNode_.next = NULL;
  }
 
  void AddAfter(NODE* node, T data)
  {
    NODE* newNode = new NODE();
 
    //
    // primeiro item?
    //
    if(node->next == NULL)
    {
      ASSERT(node->previous == NULL && node == &rootNode_);
      node->next = node->previous = node;
      node->data = data;
      return;
    }
    else
    {
      //
      // refaz todos os links, para que o nó inserido
      // fique entre o nó passado como parâmetro
      // e o próximo
      //
      newNode->next = node->next;
      node->next = newNode;
      newNode->previous = node;
      newNode->next->previous = newNode;
 
      newNode->data = data;
    }
 
    count_++;
  }
 
  void Dump()
  {
    cout << "== DUMP START ==" << endl;
 
    if(rootNode_.next == NULL)
    {
      ASSERT(rootNode_.previous == NULL);
      cout << "== DUMP END ==" << endl;
      return;
    }
 
    cout << rootNode_.data << endl;

 
    for(NODE* node = rootNode_.next ; node != &rootNode_ ; node = node->next)
      cout << node->data << endl;
 
    cout << "== DUMP END ==" << endl;
  }

 
  void Add(T data)
  {
    AddAfter(&rootNode_, data);
  }
 
  unsigned int Count()
  {
    if(rootNode_.next == NULL)
    {
      ASSERT(rootNode_.previous == NULL);
      return 0;
    }

 
    unsigned int count = 1;
 
    for(NODE* node = rootNode_.next ; node != &rootNode_ ; node = node->next)
      count++;
 
    return count;
  }

 
};
 
//
// estrutura para informar a nossa worker thread o que ela
// deve fazer
//
struct WORKER_THREAD_INFO 
{
  LinkedList<int>* list;
  unsigned int addCount;
};

 
//
// nossa "linha trabalhadora" (aposto que algum livro traduzido
// deve usar esse termo, aposto). Ela adicionará itens na 
// nossa lista ligada
//
DWORD WINAPI WorkerThread(void* lpv)
{
  WORKER_THREAD_INFO* info = (WORKER_THREAD_INFO*)lpv;
 
  for(DWORD a = 0 ; a < info->addCount; a++)
  {
    info->list->Add(a);
 
    //
    // dormir é uma boa forma de gastar um tempo
    // e simular trabalho. Pena que a Win32 API
    // não tem um função SleepInTheBathroom();
    //
    Sleep(10);
  }
 
  return 0;
}
 
int main()
{
  LinkedList<int> list;

 
  static const DWORD threadCount = 100;
  DWORD dwThreadID;
  vector<HANDLE> threads;
 
  //
  // todas as threads vão adicionar a mesma quantidade,
  // para fins de teste e demonstração está mais que bom.
  //
  WORKER_THREAD_INFO info;
  info.list = &list;
  info.addCount = 100;
 
  //
  // criando todas as threads
  //
  for(DWORD a = 0 ; a < threadCount ; a++)
    threads.push_back(CreateThread(NULL, NULL, &WorkerThread, &info, NULL, &dwThreadID));
 
  //
  // esperando TODAS as threads retornarem
  //             |___________________________________
  //                                                 |
  //                                                 v
  //
  WaitForMultipleObjects(threadCount, &threads[0], TRUE, INFINITE);
 

  list.Dump();
 
  //
  // isso deve mostrar 10.000.
  //
  cout << "count: " << list.Count();
 

  //
  // vou deixar os handles abertos, como o programa vai 
  // morrer agora o Windows se vira com isso...
  //
 
  return 0;
}

Bom, 100 threads criando 100 registros na nossa lista ligada devem criar 10.000 registros, certo? Faça alguns testes: rode primeiro em Debug. Depois rode em Release. Depois brinque com o número do Sleep. Depois repita os testes em diferentes máquinas, com diferentes clocks e quantidades de cores. Olhe algumas saídas que eu obtive durante os testes, usando um Core 2 Duo (2 cores):

== Versão Debug ==
count: 92
count: 99
count: 98
count: 99
== Versão Release ==
count: 40
count: 99
count: 97

Ué, não deveria ser 10.000? Mudando o tempo do Sleep e a quantidades de threads eu consegui outros números, completamente diferentes. Isso é o chamado race condition, um problema ou bug que depende de timming e coisas fora do seu controle, um problema típico de programação multithread. Como a manifestação do bug depende de diversos fatores fora do seu controle - velocidade do processador, carga de processamento da máquina, etc - esse tipo de problema é sempre muito difícil de reproduzir e debugar.

O principal problema desse código está no trecho de código que adiciona um item na lista:

      newNode->next = node->next;
      node->next = newNode;
      newNode->previous = node;
      newNode->next->previous = newNode;
      newNode->data = data;

Esse trecho de código deve ser executado de forma atômica para que a lista ligada continue válida, com todos os ponteiros apontando para seus próximos e anteriores de forma correta. Depois da execução da segunda linha, o estado da lista permanece inválido até que a última linha desse trecho seja executada. Como uma thread pode ser interropida a qualquer hora (inclusive entre essas linhas), a manipulação dos ponteiros é feitas de forma incorreta e desordenada. É grande a probabilidade (isso depende do scheduler) de que a última thread que estava "mexendo" na lista a tenha deixado em um estado inválido. Isso pode gerar um erro de lógica (nosso caso) ou um GPF difícil de achar, que cada hora acontece em um lugar do código.

No próximo post começaremos a ver os recursos da API do Windows para resolver esse problema e permitir que várias threads manipulem um mesmo recurso ao mesmo tempo.

0 comentário(s)

Modelagem UML Genérica

2008-06-28T20:49:33+00:00

Recebi do meu amigo Bruno, lá de Chapecó, essa excelente modelagem UML genérica que se aplica a qualquer aplicação. Agora você não precisa mais perder tempo fazendo a análise e design. É só seguir os diagramas abaixo e tudo ficará bem.

Diagrama de Classes

Diagrama de Sequência

Diagrama de Casos de Uso

Two versions for Lock-Free Stack

2008-06-24T11:09:06+00:00

The two codes below are implementations of lock-free stack structure.

The purpose is the same, but the first version can be ported easily to other OSes.

Performance benchmark is a lesson to the reader.

The raw C++ implementation. In C++0x we'll change Interlocked APIs to atomic operations:

template

<typename T>
struct LockFreeStack
{
LockFreeStack() : Head_( NULL ){}

void Push( T& value )
{
    PNODE node = new NODE( value );
    PNODE oldHead;

    do
    {
      node->Next = oldHead = Head_;
    }while( oldHead != reinterpret_cast<PNODE>( InterlockedCompareExchangePointer(
                                      reinterpret_cast<volatile PVOID*>(&Head_), node, oldHead )));
}

T Pop()
{
    PNODE node;
    PNODE oldHead;

    do
    {
      oldHead = Head_;
    }while( oldHead != (node = reinterpret_cast<PNODE>( InterlockedCompareExchangePointer(
                                            reinterpret_cast<volatile PVOID*>(&Head_), Head_->Next, oldHead ))));

    T temp = node->Data;
    delete node;
    return temp;
}

private:
typedef struct NODE_TAG
{
    NODE_TAG( T value ) : Next(NULL), Data(value){}
    NODE_TAG* Next;
    T Data;
} NODE, *PNODE;

PNODE Head_;

LockFreeStack( const LockFreeStack& ){}
LockFreeStack& operator=( const LockFreeStack& ){}
};

Using a Windows API facility called Singly Linked Lists:

template<typename T>
struct LockFreeStack
{
LockFreeStack()
{
    Head_ = new_aligned<SLIST_HEADER>();
    if( NULL == Head_ )
      throw "memory allocation failed";

    InitializeSListHead( Head_ );
}

~LockFreeStack()
{
    InterlockedFlushSList( Head_ );
}

void Push( T value )
{
    Item_ = new_aligned<ITEM>();
    if( NULL == Item_ )
      throw "stack is full";

    Item_->Value = value;
    Entry_ = InterlockedPushEntrySList( Head_, &Item_->Entry );
}

T Pop()
{
    PSLIST_ENTRY tempEntry = InterlockedPopEntrySList( Head_ );
    if( NULL == tempEntry )
      throw "stack is empty";

    Item_ = reinterpret_cast<PITEM>( tempEntry );
    T temp = Item_->Value;
    _aligned_free( tempEntry );
    return temp;
}

private:
typedef struct ITEM_TAG
{
    SLIST_ENTRY Entry;
    T Value;
} ITEM, *PITEM;

PSLIST_ENTRY Entry_;
PSLIST_HEADER Head_;
PITEM Item_;

template <class M> M* new_aligned()
{
    return reinterpret_cast<M*>(_aligned_malloc( sizeof(M), MEMORY_ALLOCATION_ALIGNMENT ));
}

LockFreeStack( const LockFreeStack& ){}
LockFreeStack& operator=( const LockFreeStack& ){}
};

A volta dos que foram mas voltaram logo

2008-06-21T19:42:44+00:00

Algumas notícias importantes para movimentar meu quase abandonado site enquanto eu fico pensando em uma boa desculpa para essa situação:

Voltei para São Paulo, e conseqüentemente, estou quase toda terça degustando um chopp no Bar Barão. Sim, isso é um convite. Para todos.
O seminário da Tempo Real sobre Portabilidade e Performance foi muito bom, muito bom mesmo. Parabéns a todos nós do "C/C++ Brasil" por fazermos eventos com qualidade técnica tão alta, coisa que eu nunca vi nessas bandas. Fico feliz por poder compartilhar o que eu aprendi em incontáveis horas programando, dezenas de livros e outras dezenas de sites e artigos lidos. E fico muito mais feliz em poder aprender com pessoas que percorreram esse mesmo caminho, muitos que estudaram e leram muito mais do que eu. Eu sei que sou bom nesse negócio de programação (modéstia é um defeito que eu não tenho), mas minha vontade de aprender ainda é bem maior que meu ego. É **muito** bom conhecer e compartilhar conhecimento com gente que é melhor do que eu. Parabéns e obrigado a todos.
Depois de mais de um mês offline (sim, essa é a desculpa), segue aqui a apresentação usada na minha palestra "Portabilidade via STL e Boost", onde eu fiz pelo STL e Boost o que os palestrantes da Microsoft/Sun/IBM/etc costumam fazer pelas empresas que pagam seus salários:

Como um trecho de código vale mais do que uma apresentação cheia de piadinhas não-tão-engraçadas, segue o dito cujo que usei durante a demo da palestra:


#define _CRT_SECURE_NO_WARNINGS
#define _SCL_SECURE_NO_WARNINGS
 
#include <vector>
#include <string>

#include <sstream>
 
#include <iostream>
 
 
#include <boost/thread.hpp>
#include <boost/bind.hpp>
#include <boost/asio.hpp>
#include <boost/function.hpp>
#include <boost/array.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/shared_array.hpp>
#include <boost/enable_shared_from_this.hpp>
#include <boost/ptr_container/ptr_map.hpp>
#include <boost/ptr_container/ptr_set.hpp>
#include <boost/algorithm/string.hpp>
#include <boost/algorithm/string/join.hpp>
#include <boost/format.hpp>
#include <boost/date_time/gregorian/gregorian.hpp>
 
#include <boost/program_options.hpp>
 
#include <boost/tuple/tuple.hpp>
 
#include <boost/foreach.hpp>
 
#include "boost/filesystem.hpp" 
#include <iostream>          
 
using namespace std;
using boost::lexical_cast;
using boost::format;
using boost::shared_ptr;
 
boost::mutex log_mutex;
 
void Log(int level, const string& str)
{
	boost::mutex::scoped_lock l(log_mutex);
 
	cout << 
		boost::format("%d - %s") % level % str
		<< endl;
}
 
 
void f(int level, string s1, string s2)
{
	Log(level, s1 + string(" ") + s2);
}
 
typedef vector<shared_ptr<boost::thread> > UmVectorDeThreads;
 
UmVectorDeThreads Test_Threads()
{
#if 0
	boost::array<boost::thread, 32> threads;
	threads.at(2) = boost::thread(boost::bind(&f, "Eu programa aos sábados.", "E daí"));

#endif
 
	boost::array< shared_ptr<boost::thread>, 32> threads;
 
	for(unsigned int i = 0 ; i < threads.size() ; i++)
	{
		threads[i] = shared_ptr<boost::thread>(
			new boost::thread(
			boost::bind(&f, 2, "Eu programo aos sabados.", 
			lexical_cast<string>(i))));
	}
 
	//
	// ai...
	//
	for(boost::array< shared_ptr<boost::thread>, 32>::iterator i 
		= threads.begin() ; i != threads.end() ; ++i)
	{
 
	}
 
	BOOST_FOREACH(shared_ptr<boost::thread> t, threads)
	{
 
	}
 
	boost::thread t;
 
 
	UmVectorDeThreads threads2(threads.size());
 
	std::copy(threads.begin(), threads.end(), threads2.begin());
 
	return threads2;
}
 
void VamosEsperarAsThreads(UmVectorDeThreads& threads)
{
	BOOST_FOREACH(shared_ptr<boost::thread> t, threads)
	{
		t->join();
	}
}
 
void Test_FileSystem()
{
	using namespace boost::filesystem;          
	path p("c:\\temp\\abobrinha");
 
	for(path::iterator i = p.begin() ; i != p.end() ; ++i)
		cout << *i << endl;
}
 
 
void Test_STL()
{
	vector<string> v;
	list<string> l;
	map<int, string> m;
 
	for(int a = 0 ; a < 20 ; a++)
	{
		string nome = "Nome " + lexical_cast<string>(a);
		v.push_back(nome);
		m[a] = nome;
	}
 
	copy(v.begin(), v.end(), back_inserter(l));
 

	BOOST_FOREACH(const string& nome, v)
		cout << nome << endl;
 
	for_each(l.begin(), l.end(), boost::bind(&Log, 1, _1));
}
 
int main()
{
	UmVectorDeThreads threads = Test_Threads();
 
	Test_STL();
	Test_FileSystem();
 
	for_each(threads.begin(), threads.end(), 
		boost::bind(&boost::thread::join, _1));
 
	//
	// olha mamãe, sem desalocar memória
	//
	return 0;
}

7 comentário(s)

Samples from my Concurrency Talk at Seminário TempoReal C++ Portabilidade e Performance

2008-06-13T13:11:13+00:00

Samples from my Concurrency Talk at Seminário TempoReal C++ Portabilidade e Performance:

Concurrency C++ Samples
Concurrency C++ Slides (in brazilian portuguese)

The following code is a C++ port to one of my previous samples: MapReduce with Parallelspace

#include

<iostream>
#include <fstream>
#include <vector>
#include <map>
#include <string>
#include <boost/thread/thread.hpp>
#include <boost/thread/mutex.hpp>
#include <boost/filesystem.hpp>
#include <boost/function.hpp>
#include <boost/algorithm/string.hpp>

using namespace std;
using namespace boost;
using namespace boost::filesystem;

void get_files( const path& directory, vector<path>& files )
{
directory_iterator end_iter;
for( directory_iterator iter( directory ); iter != end_iter; ++iter )
{
if( is_directory( iter->status() ) ) continue;
files.push_back( iter->path() );
}
}

int get_ProcessorCount(){ return 2; }

class TaskExecutor
{
typedef function2<void, map<string, int>&, const map<string, int>&> ConsolidationFunctionType;
typedef function1<map<string, int>, const path&> CountWordsFunctionType;

public:
TaskExecutor( vector<path>::const_iterator begin, vector<path>::const_iterator end,
                      const CountWordsFunctionType countWords,
                      const ConsolidationFunctionType consolidation,
                      map<string, int>& result ) : Begin_( begin ),
                      End_( end ),
                      CountWordsFunction_( countWords ),
                      ConsolidationFunction_( consolidation ),
                      Result_( result ){}

void operator()()
{
for( vector<path>::const_iterator iter = Begin_; iter != End_; ++iter )
ConsolidationFunction_( Result_, CountWordsFunction_( *iter ) );
}

private:
vector<path>::const_iterator Begin_, End_;
const ConsolidationFunctionType ConsolidationFunction_;
const CountWordsFunctionType CountWordsFunction_;
map<string, int>& Result_;
};

void key_count( map<string, int>& dictionary, const string& word, int value )
{
dictionary[ word ] = dictionary.end() != dictionary.find( word ) ? dictionary[ word ] + value : value;
}

map<string, int> map_function( const path& filename )
{
map<string, int> wordCount;

ifstream file;
const int MAXLEN = 1024;
char line[ MAXLEN ];

file.open( filename.directory_string().c_str() );

while( file.getline( line, MAXLEN ) )
{
    vector<string> split_v;
    split( split_v, string( line ), is_any_of( " " ) );
    for( vector<string>::const_iterator iter = split_v.begin(); iter != split_v.end(); ++iter )
      key_count( wordCount, *iter, 1 );
}

file.close();

return wordCount;
}

void reduce_function( map<string, int>& destination, const map<string, int>& source )
{
for( map<string, int>::const_iterator iter = source.begin(); iter != source.end(); ++iter )
key_count( destination, iter->first, iter->second );
}

void wordcount_mapreduced( const vector<path>& files, map<string, int>& wordCount )
{
//data partition
int numberOfPartitions = get_ProcessorCount() * 2; //2 threads per core
int numberOfFiles = static_cast<int>( files.size() );
if( numberOfFiles < numberOfPartitions ) numberOfPartitions = numberOfFiles;
int delta = numberOfFiles / numberOfPartitions;
vector< map<string, int> > result( numberOfPartitions );
thread_group tg;

//for parallel
for( int step = 0; step < numberOfPartitions; ++step )
{
    vector<path>::const_iterator begin = files.begin() + delta * step,
    end = numberOfPartitions - 1 == step ? files.end() : files.begin() + delta * step + delta;
    //fork
    tg.create_thread( TaskExecutor( begin, end, map_function, reduce_function, result[step] ) );
}

//join
tg.join_all();
for( vector< map<string, int> >::const_iterator iter = result.begin(); iter != result.end(); ++iter )
reduce_function( wordCount, *iter );
}

int main()
{
vector<path> files;
get_files( "c:\\txttest\\", files );
map<string, int> wordCount;

wordcount_mapreduced( files, wordCount );

for( map<string, int>::const_iterator iter = wordCount.begin(); iter != wordCount.end(); ++iter )
cout << iter->first << " = " << iter->second << endl;
}

Instalador da boost

2008-06-08T19:55:48+00:00

Para quem ainda tem dificuldades para compilar a biblioteca boost, eu encontrei um instalador que baixa os pacotes dependendo de suas escolhas (multithreaded, static, debug, etc) sem contar que nos polpa de ter que esperar pela compilação, pena que é só para o Visual C++.

O instalador pode ser baixado aqui, mais informações em http://www.boost-consulting.com/products/free

Declaração x definição

2008-06-06T12:27:33+00:00

Uma diferença que eu considero crucial na linguagem C/C++ é a questão da declaração/definição (em inglês, declaration/definition). É a diferença entre esses dois conceitos que permite, por exemplo, que sejam criadas estruturas prontas para serem conectadas a listas ligadas:

struct Element
{
   int x;
   int y;
   Element* next; /* olha eu mesmo aqui! */
};

Por outro lado, e mais importante ainda, é ela que permite que as funções sejam organizadas em unidades de tradução (cpps) distintas para depois se unirem durante o link, mesmo que entre elas exista uma relação de dependência indissociável:

Existem diversas formas de entender esses dois conceitos. Eu prefiro explicar pela mesma experiência que temos quando descobrimos a divisão hardware/software:

Hardware é o que você chuta
Software é o que você xinga

Exatamente. Hardware é algo paupável, que você pode até chutar se quiser. Por exemplo, a sua memória RAM! No entanto, software é algo mais abstrato, que nós, seres humanos, não temos a capacidade de dar umas boas pauladas. Portanto, nos abstemos a somente xingar o maldito que fez o programa "buggento".

Da mesma forma, uma declaração em C/C++ nos permite moldar como será alguma coisa na memória, sem no entanto ocupar nem um mísero byte no seu programa:

int func(int x, int y, int z); /* tamanho em memória: zero bytes */

struct Teste
{
	char bufao[0x100000]; /* tamanho em memória: zero bytes */
	int intao[0xffffff];  /* tamanho em memória: zero bytes */
};

extern int x; /* tamanho em memória: adivinha! */

Por outro lado, a definição, o hardware da história, sempre ocupará alguma coisa na memória RAM, o que, de certa forma, permite que você chute uma variável (embora muitas outras também irão para o saco).

int func(int x, int y, int z) /* tamanho em memória:
{
	int ret = x + y + z; /* alguns _asm add + */
	return ret;          /* um _asm ret */
}

Teste tst; /* tamanho em memória: 0x100000 + 0xffffff * 4 = 1048576 bytes */

int x; /* tamanho em memória: sizeof(int) bytes */

Dessa comparação só existe uma pegadinha: uma definição também é uma declaração. Por exemplo, nos exemplos acima, além de definir func, tst e x, o código também informa ao compilador que existe uma função chamada func, que existe uma variável tst do tipo Teste e uma variável x do tipo int.

Informa ao compilador? Essa é uma outra ótima maneira de pensar a respeito de declarações: elas sempre estão conversando diretamente com o compilador. Por outro lado, nunca conversam diretamente com o hardware, pois ao executar seu código compilado, as declarações não mais existem. Foi apenas um interlúdio para que o compilador conseguisse alocar memória da maneira correta.

Complicado? Talvez seja, mesmo. Mas é algo que vale a pena fixar na mente. Isso, é claro, se você quiser ser um programador C/C++ mais esperto que os outros e resolver pequenos problemas de compilação que muitos perdem horas se perdendo.

Corolário

Então por que diabos a separação declaração/definição consegue definir coisas como listas ligadas, como no código acima? A resposta é um pouco ambígua, mas representa regra essencial na sintaxe da linguagem: após a definição do nome e do tipo de declaração envolvida podemos referenciá-la como declaração, ou seja, não ferindo a limitação de que não sabemos o tamanho de uma variável do tipo declarado. Dessa forma, é perfeitamente legal definirmos um ponteiro para uma estrutura que ainda não se sabe muita coisa, além de que é uma estrutura:

struct Estrutura; /* atenção: declaração apenas! */

Estrutura* st; /* ponteiro para declaração: não sabemos o tamanho ainda */

Dessa forma, o começo de uma definição de estrutura já declara o nome da estrutura antes de terminar a declaração do tipo inteiro. Bizarro, não? De qualquer forma, isso permite a construção clássica de lista ligada:

struct Estrutura /* a partir daqui Estrutura já está visível */
{
	Estrutura* st; /* recursividade? é apenas um ponteiro! */
};

Se vermos pelo lado prático, de qualquer forma seria impossível definir uma variável dentro dela mesma, pois isso geraria uma recursão infinita de definições, e, como sabemos, os recurso da máquina são finitos.

Agendamento de Tarefas

2008-06-05T20:18:50+00:00

Essa é minha implementação de um pequeno sistema de agendamento de tarefas, que futuramente usarei em um outro projeto, achei que ficou legal então resolvi postar. Vamos à implementação

task.hpp

#ifndef _task_hpp
#define _task_hpp

#include <ctime>
#include <boost /function.hpp>
#include </boost><boost /bind.hpp>

class task
{
	public:
		explicit task(const boost::function<void ()>& callback)
		: _call_back(callback)
		, _call_count(0)
		, _total_time_used(0)
		{
		}

		virtual ~task() { }

		virtual void before_task() { }

		void do_task()
		{
			before_task();
			_call_back();
			after_task();
		}

		virtual void after_task() { }

		void set_callback(const boost::function</void><void ()>& callback)
		{
			_call_back = callback;
		}

		const boost::function</void><void ()>& get_callback() const
		{
			return _call_back;
		}

		bool is_valid() const
		{
			return true;
		}

	private:
		boost::function</void><void ()> _call_back;
		std::size_t _call_count;
		std::clock_t _total_time_used;
};

#endif

schedule.hpp

#ifndef _schedule_hpp
#define _schedule_hpp

#include <algorithm>
#include <deque>
#include <boost /pool/pool_alloc.hpp>
#include </boost><boost /shared_ptr.hpp>
#include </boost><boost /noncopyable.hpp>
#include </boost><boost /thread/thread.hpp>
#include </boost><boost /thread/xtime.hpp>
#include </boost><boost /thread/mutex.hpp>

#include "task.hpp"

using std::for_each;
using std::deque;
using boost::shared_ptr;

class task;
typedef shared_ptr<task> task_ptr;
typedef deque<task_ptr , boost::pool_allocator<task_ptr> > deque_task;

class schedule : public boost::noncopyable
{
	public:
		schedule() : job(boost::bind(&schedule::thread_dispatcher, this))
		{
			_thread_sleep.sec = 10;

			try
			{
				job.join();
			}

			catch (boost::thread_interrupted&) { /* don't care... */ }
		}

		virtual ~schedule() { }

		void add_task(const shared_ptr<task>& _task)
		{
			boost::mutex::scoped_lock lock(monitor);

			deque_task::const_iterator it = std::find(_task_pool.begin(),
					_task_pool.end(), _task);

			if (it == _task_pool.end())
			{
				_task_pool.push_back(_task);
			}

			else {
				// duplicate item
			}
		}

		void remove_task(const shared_ptr</task><task>& _task)
		{
			boost::mutex::scoped_lock lock(monitor);

			deque_task::iterator it = std::find(_task_pool.begin(),
					_task_pool.end(), _task);

			if (it != _task_pool.end())
			{
				_task_pool.erase(it);
			}

			else {
				// does't exist
			}
		}

	protected:
		void thread_dispatcher()
		{
			for (;;)
			{
				for_each(_task_pool.begin(), _task_pool.end(),
					boost::mem_fn(&task::do_task));

				boost::thread::sleep(_thread_sleep);
			}
		}

	private:
		deque_task _task_pool;
		boost::thread job;
		boost::mutex monitor;
		boost::xtime _thread_sleep;
};

#endif

Unidade para testes, main.cpp

#include <iostream>
#include <boost /scoped_ptr.hpp>
#include </boost><boost /bind.hpp>

#include "schedule.hpp"

void f1()
{
	std::cout < < "f1()" << std::endl;
}

void f2()
{
	std::cout << "f2()" << std::endl;
}

int main()
{
	boost::scoped_ptr<schedule> _schedule(new schedule());

	shared_ptr<task> _task1 (new task(f1));
	shared_ptr</task><task> _task2 (new task(f2));

	_schedule->add_task(_task1);
	_schedule->add_task(_task1); // repetido, nao insere...
	_schedule->add_task(_task2);

	_schedule->start();

	return 0;
}

Agradecimentos

Daniel pela sugestão de usar fila e apenas uma thread ao invés de uma para cada tarefa e assim evitando busy-waiting
Alex pelos testes de compatibilidade com mingw e msvc (vide mem_fun e shared_ptr)

schedule.zip

Resultado do Seminário CCPP

2008-06-03T00:17:05+00:00

Aconteceu nesse fim-de-semana, como era previsto, o nosso primeiro Seminário CCPP Brasil, com direito a pessoas de todas as idades e origens, mas todas com algo em comum: a paixão e o interesse pelas linguagens-mestre do mundo da programação.

Começo esse artigo agradecendo a todos os que direta e indiretamente participaram para o sucesso do evento, entre eles os organizadores, o carro-chefe responsável por acordar o espírito C++ da galera no início do ano, os palestrantes e, claro, óbvio, toda a comunidade C++ que participou em corpo (vulgo hardware) e alma (vulgo software).

Termino a introdução fazendo uma minicrítica ao preço pago pelos participantes. Não que eu ache que seja muito, pelo contrário: dado o alto nível técnico das palestras, parece até mentira termos acesso a um evento com essa estrutura por tão pouco. Porém, o muito e o pouco são relativos, e ainda acredito que existam pessoas que não vão aos encontros por falta de recursos. Por isso mesmo vai um apelo para que nos futuros encontros tenhamos alguma forma de permitir às pessoas menos favorecidas de participar democraticamente dessa que é a expressão viva das linguagens C e C++ em nosso país.

Vamos às palestras!

Dicas e Truques de Portabilidade
Wanderley Caloni

Apresentação para baixar em PDF, PPT e ODP.

É muito difícil analisar uma palestra feita por você mesmo. É mais difícil ainda quando essa palestra é a primeira de uma batelada de argumentações de alto nível técnico que seguiram o dia. Posso dizer, no entanto, que consegui o que queria quando fui para o evento: demonstrar as dificuldades e as facilidades de tornar um código portável, independente se entre sistemas operacionais, ambientes ou compiladores.

Foi visto primeiramente o que faz da portabilidade uma coisa difícil. Detalhes como sintaxe e gramática fazem toda a diferença quando o que se almeja é um código limpo de imperfeições trazidas pelo ambiente de desenvolvimento. Também foi dada especial atenção às famigeradas extensões de compiladores, que fazem a linguagem parecer uma coisa que não é.

Por fim, foram apresentadas algumas sugestões movidas pela experiência e estudo dessas mesmas dificuldades. Para ilustrar, dois exemplos bem vivos de como um código portável deve se comportar, tanto no código-fonte quanto em sua documentação.

Programação Concorrente com C++
Fábio Galuppo

Artigo sobre apresentação

Para quem está acostumado com os temas geralmente "gerenciados" de Fábio Galuppo com certeza deve ter se surpreendido com a descrição teórica dos inúmeros problemas que cercam a vida do programador multithreading. O palestrante partiu do mais simples, o conceito de threads, conceito que, segundo ele mesmo, pode ser explicado em 15 minutos, para algo mais sutil e que gera muitos erros escondidos: o conceito de locks (semáforos, mutexes, etc).

Os programadores em nível de sistema devem ter adorado o contexto histórico dos problemas (você sabia que o primeiro lock inventado foi o semáforo?) tanto quanto o contexto teórico (explicação sobre modelo de memória).

Um destaque especial foram os experimentos com código rodando de verdade no Visual Studio, como o exemplo que tenta criar o maior número de threads possível na arquitetura 64. Simplesmente assustador!

Se por um lado faltou tempo para explicar os usos e princípios das bibliotecas de programação paralela disponíveis e mais usadas do mercado, por outro a palestra preencheu uma lacuna importante na minha primeira palestra sobre threads em C++, demonstrando os erros mais comuns e o que não se deve fazer em programas que rodam mais de uma thread.

Mais uma vez voltando à teoria, a palestra foca mais uma vez em bons princípios de design, como o padrão de projeto monitor e a descrição dos modelos onde é justificado o uso de mais de uma thread no programa.

Programação Multiplataforma Usando STL e Boost
Rodrigo Strauss

Como sempre, Strauss está apaixonado pelo Boost (e a STL). Descrevendo as partes mais importantes que todo programador C++ moderno deve saber sobre essas bibliotecas, ambas modernas, a palestra focou principalmente no uso do dia-a-dia, e as vantagens produtivas que o C++ atual pode ter sobre o velho e tradicional programa em C com listas encadeadas artesanais.

Entre as coisas mais importantes citadas, que todo programador do novo século deveria saber, estão:

A total falta da necessidade de desalocarmos objetos manualmente em nossos programas, visto que o auto_ptr (STL) e shared_ptr (Boost) dão conta do recado de maneira impecável.
A total falta da necessidade de usarmos aqueles velhos arrays em C que quase nunca sabemos o tamanho exato para guardar nossos valores (e que continuamente colocávamos com o tamanho 100, MAX_PATH, ou UM_OUTRO_DEFINE_COMUM_EM_LINUX). A classe boost::array provê todas as funcionalidades básicas, além das avançadas, do uso de arrays tradicionais, sem qualquer overhead adicional de um array em C.
A total falta de necessidade de ficar convertendo strings e inteiros. Com a ajuda da classe std::string e de construções geniais como lexical_cast (Boost), felizmente podemos deixar nossas velhas funções que precisavam de um buffer, como _itoa (embora não-padrão).

Enfim, para quem pôde ver, a palestra focou nos princípios que farão hoje em dia um programador C++ completo, profissional e que, como seus colegas de outras linguagens, se preocupa igualmente com a produtividade de seu código. Ah, sim, e não gosta nem um pouco de reinventar a roda.
Técnicas de Otimização de Código
Rodrigo Kumpera & André Tupinambá

Aparentemente o que pensei que seria, em minha sincera opinião, um desastre (dois palestrantes falando sobre a mesma coisa) se transformou em uma combinação estupenda de teoria e prática aplicadas à arte de otimização de código. Rodrigo e André conseguiram destrinchar o tema harmoniosamente, sempre dividido entre técnicas avançadas (algumas demonstradas pela experiência dos palestrantes) e teoria disciplinar, que visa alertar o wannabe que otimizar pode ser uma coisa boa; porém, preste atenção aos que já fizeram isso têm a dizer.

Com uma didática impecável, o novato nesse tema (como eu) pôde ver as dificuldades de conseguir determinar o objetivo de todo otimizador de código que, segundo eles, deve estar sempre atento na máxima de que "toda otimização é na verdade uma troca". Ou seja, se o programador quer melhor processamento, pagará com memória, se quiser otimizar espaço na RAM, irá gastar mais com processamento e/ou disco, e assim por diante.

Foram apresentados exemplos reais de otimização, além de dicas muito importantes sobre o comportamento das compilaçõe de cada dia. Você sabia, por exemplo, que ao declarar em escopos mais locais suas variáveis usadas apenas em pequenos trechos de código, estará dando uma poderosa dica ao compilador para que ele consiga usar os registradores no máximo de sua capacidade?

Conclusão: estamos indo de bem a melhor!

Ao final, como é de praxe, tivemos um sorteio de ótimos livros sobre programação e C++ em geral, com destaque aos livros do Herb Sutter. Rodrigo Strauss, conhecido fundador dos encontros, recebeu sua mais que merecida homenagem ao receber um de seus livros autografados. É o mais novo MVP da comunidade!

E por falar em comunidade, e agora podemos ver claramente, estamos com uma força bem maior do que no início do ano. A seqüência de ótimos eventos, além de nossos mestres do conselho Jedi de programadores C++, prova finalmente que, se depender da qualidade dos desenvolvedores, o Brasil pode sim ser uma poderosa fonte de programas de qualidade que façam coisas bem mais interessantes do que acessar um banco SQL. Nós já temos a matéria-prima.

Mais linques sobre o evento

Discussão sobre o evento na nossa lista

Imagens do evento cedidas por Fernando Roberto (valeu, Ferdinando!).

Dica: Corrigindo erro da user32.lib no CMake com NMake Makefiles

2008-05-31T17:59:21+00:00

No CMake, quando se usa o gerador NMake Makefiles ele costuma dar o erro:

LINK : fatal error LNK1104: cannot open file 'user32.lib' LINK Pass 1 failed. with 2 NMAKE : fatal error U1077: ‘”C:\Arquivos de programas\CMake 2.6\bin\cmake.exe”‘ : return code ‘0xffffffff’ Stop. NMAKE : fatal error U1077: ‘”C:\Arquivos de programas\Microsoft Visual Studio 8\VC\BIN\nmake.exe”‘ : return code ‘0×2′ Stop.

Mesmo que você tenha o Microsoft Platform SDK, isso ocorre porque o linker não consegue encontrar a user32.lib. Para projetos que usam o gerador do Visual Studio você pode configurar isso seguindo as recomendações da configuração do SDK, mas para resolver este problema em projetos que usam a NMake, você precisa adicionar o path da user32.lib na variável de ambiente LIB. Você pode fazer isso na mão, após iniciar o prompt de comando do Visual Studio:

set LIB=%LIB%;"C:\Arquivos de programas\Microsoft Platform SDK\Lib"

Ou então adicionar o path nas variáveis de ambiente do sistema através da aba “Avançado” nas propriedades do sistema.

deque + shared_ptr + for_each + mem_fun = cabumm

2008-05-28T16:03:04+00:00

Recentemente tive problemas com mem_fun e shared_ptr em um loop for_each

Os elementos

typedef shared_ptr<task> task_ptr;
typedef deque<task_ptr , pool_allocator<task_ptr> > deque_task_ptr;

Agora a combinação explosiva

for_each(_task_pool.begin(), _task_pool.end(),
       std::mem_fun(&task::do_task));

O problema está em usar std::mem_fun, ela não suporta chamar métodos de uma classe que estão em um shared_ptr, eu poderia ter usado bind, mais preferi manter o código, como a boost tem sua própria implementação de mem_fn ficando assim:

for_each(_task_pool.begin(), _task_pool.end(),
       boost::mem_fn(&task::do_task));

Resolvido, obrigado Alex por reportar o problema.

IDE online

2008-05-21T10:56:44+00:00

Meu amigo Diego me passou a dica sobre o CodeIDE. Segundo ele, é um site onde pode executar códigos, suporta várias linguagens como Pascal, C++, Perl, JavaScript, HTML, e outras. Você digita o código, e mandar executar, já ve o resultado na página mesmo. O site também oferece suporte a chat e grupos, o que possibilita vc explicar o código para alguém, discutir sobre um código, etc, etc. Aqui tem um artigo sobre o site
http://blog.cidandrade.pro.br/technology/interface-online-para-ensino-de-programacao-codeide/ …

Eu achei o site uma grande mão na roda pra quando você quer mostrar alguma técnica ou explicar algo para alguém. Além disso, ele tem um recurso de realce de sintaxe (syntax highlight) que melhora a percepção do código.

Membros privados em estruturas C

2008-05-19T00:08:31+00:00

Esta semana, lá no trabalho tive mais uma prova que paradigma de programação é algo completamente independente de linguagem, ou seja, não é pelo fato de você estar programando em C++, compilando com o g++ que o seu código vai ser orientado a objetos, tão pouco, se você programa em ANSI C o seu código obrigatoriamente vai ser estruturado ou você estará impedido de programar orientado a objetos.

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 - não por mim ) 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 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 struc 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 encontra-lo.
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 ele pois ele nada sabe a respeito de qual o espaço que 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

Dica: XPath

2008-05-16T05:15:40+00:00

O XPath é uma linguagem para seleção de nós em um documento XML. Entre outas coisas, é bastante utilizada quando se trabalha com XSLT. Como ela também é suportada em diversas bibliotecas ela é comumente utilizada com C (libxml2), C++ (xalan, xerces, etc), Java (jaxp, etc), Python, e muitas outras linguagens
Hoje, precisei fazer uma expressão para obter um nó somente quando o nó pai fosse igual a um determinado valor e tivesse algum atributo específico.

<paises continente="Europa"/>
<pais nome="Portugal"/>
<pais nome="França" />
</paises>
<paises continente="Africa" />
<pais nome="Angola"/>
</paises>

Vamos supor que você quisesse obter o nó referente a Angola. Você poderia faze-lo através da seguinte expressão:

PLAIN TEXT

CODE:

//paises[@continente='Africa']/pais[@nome='Angola']

No caso a expressão // representa os nós descendentes ou o próprio e a expressão @ representa um atributo. A expressão completa representa um caminho para o nó (de modo análogo /usr/share ou C:/windows representam um caminho no disco rígido).
Mais sobre XPath neste excelente tutorial.

Aquele do-while engraçado

2008-05-15T03:35:31+00:00

Nesses últimos dias andei conversando com um amigo que está estudando sistemas operacionais na faculdade. Melhor ainda, vendo o código real de um sistema operacional em funcionamento. A conseqüência é que, além de aprender um bocado de como as coisas funcionam de verdade debaixo dos panos, acaba-se aprendendo alguns truquezinhos básicos e tradicionais da linguagem C.

Por exemplo, é um hábito conhecido o uso de construções do-while quando existe a necessidade de definir uma macro que possui mais de um comando em vez de usar a igualmente conhecida { construção de múltiplos comandos entre chaves }.

O que talvez não seja tão conhecido é o porquê das coisas serem assim.

Vamos imaginar uma macro de logue que é habilitada em compilações debug, mas é mantida em silêncio em compilações release:

#ifdef NDEBUG
 
#define MYTRACE( message ) /* nothing */
 
#else
 
#define MYTRACE( message )        \
	{                              \
		char buffer[500];           \
		sprintf(buffer,             \
			"MYTRACE: %s(%d) %s\n",  \
			__FILE__,                \
			__LINE__,                \
			message);                \
		OutputDebugString(buffer);  \
	}
 
#endif /* NDEBUG */

Nada de mais, e parece até funcionar. Porém, como veremos nas próximas linhas, esse é realmente um exemplo de código "buguento", já que uma chamada dentro de uma construção if-else simplesmente não funciona.

if( exploded() )
	MYTRACE("Oh, my God");
else
	MYTRACE("That's right");

error C2181: illegal else without matching if

Por que isso? Para responder a essa questão nós precisamos olhar um pouco mais de perto no resultado do preprocessador da linguagem, que apenas troca nossa macro pelo pedaço de código que ela representa:

if( exploded() )
	{
		char buffer[500];
		sprintf(buffer,
			"MYTRACE: %s(%d) %s\n",
			__FILE__,
			__LINE__,
			"Oh, my God");
		OutputDebugString(buffer);
	};
else
	{
		char buffer[500];
		sprintf(buffer,
			"MYTRACE: %s(%d) %s\n",
			__FILE__,
			__LINE__,
			"That's right");
		OutputDebugString(buffer);
	};

Dessa forma, podemos ver o porquê. Quando chamamos a macro, geralmente usamos a sintaxe de chamada de função, colocando um sinal de ponto-e-vírgula logo após a chamada. Essa é a maneira correta de se chamar uma função, mas no caso de uma macro, dessa macro, é um desastre, porque ela cria dois comandos em vez de um só (um ponto-e-vírgula vazio, apesar de não fazer nada, é um comando válido). Então, isso é o que o compilador faz:

if( instruction )
{
	/* um monte de comandos */

} /* aqui eu esperaria um else ou uma instrução nova */

; /* uma instrução nova! ok, sem else desa vez */

else /* espere ae! o que esse else está fazendo aqui sem um if?!?! */
{
	/* mais comandos */
}

Pense sobre o comando vazio como se ele fosse um comando real, o que é a maneira mais fácil de entender o erro de compilação que recebemos ao compilar o código abaixo:

if( error() )
{
	printf("error");
}

printf("here we go");

else /* llegal else without matching if! */
{
	printf("okay");
}

Por essa razão, a maneira tradicional de escapar desse erro comum é usar uma construção válida que peça de fato um ponto-e-vírgula no final. Felizmente nós, programadores C/C++, temos essa construção, e ela é... muito bem, o do-while!

do
{
	/* múltiplos comandos aqui */
}
while( expression ) ; /* eu espero um ponto-e-vírgula aqui, para
                         finalizar minha instrução do-while */

Assim nós podemos reescrever nossa macro de logue da maneira certa (e todas as 549.797 macros já escritas em nossa vida de programador). E, apesar de ser uma construção um tanto bizarra, ela funciona melhor do que nossa tentativa inicial:

#ifdef NDEBUG
 
#define MYTRACE( message ) /* nothing */
 
#else
 
#define MYTRACE( message )        \
	do                             \
	{                              \
		char buffer[500];           \
		sprintf(buffer,             \
			"MYTRACE: %s(%d) %s\n",  \
			__FILE__,                \
			__LINE__,                \
			message);                \
		printf(buffer);             \
	}                              \
	while( 0 )
 
#endif /* NDEBUG */

Ao usar um do-while (com uma expressão que retorna falso dentro do teste, de maneira que o código seja executado apenas uma vez) a construção if-else consegue funcionar perfeitamente:

if( exploded() )
	do
	{
		char buffer[500];
		sprintf(buffer,
			"MYTRACE: %s(%d) %s\n",
			__FILE__,
			__LINE__,
			"Oh, my God");
		OutputDebugString(buffer);
	}
	while( 0 );
else
	do
	{
		char buffer[500];
		sprintf(buffer,
			"MYTRACE: %s(%d) %s\n",
			__FILE__,
			__LINE__,
			"That's right");
		OutputDebugString(buffer);
	}
	while( 0 );