Enviado em 06/06/2016 - 21:50h
Eu não tenho tempo de participar de um projeto desses, então desejo sucesso de longe. Se tiver dúvidas, traga aqui para o fórum, e -- quem sabe? -- talvez eu possa ajudar assim, mais difusamente.
Permita-me uma primeira sugestão (que pode fazer mais ou menos sentido, a depender do contexto). Você deu como exemplo do que pretende fazer o seguinte código:
//SDL
O que eu sugiro é uma mudança um pouco mais profunda na forma de atribuir nomes aos seus tipos e métodos. Se C possui apenas um espaço para todos os nomes e muito pouco acoplamento entre as funções e os dados que elas podem receber como argumentos, e compensa isso por meio de afixos dados aos nomes (por exemplo: uma função chamada
SDL_RedererClear () que recebe argumento do tipo
struct SDL_Renderer * ), C++ possui a possibilidade de compartimentar espaços de nomes e permite ligar funções especificamente a determinados tipo de dados, fazendo-as “métodos” das classes que definem esses dados.
Valendo-se disso, você poderia transformar a linha em C++ acima, deixando-a com a seguinte cara:
renderer->clear();
Por sua vez, a declaração de
renderer (que você não mostrou nos exemplos acima) poderia ser, no caso em C++, assim:
sdl::renderer *renderer; // Sem conflito de nomes porque os namespaces são diferentes
Para tanto, eis como você poderia montar a classe
sdl::renderer :
NOTAS SOBRE O CÓDIGO ABAIXO: (1) Como sdl::renderer tem dependências de outras classes (uma para envelopar SDL_Window e uma para representar exceções), eu dou uma passada muito superficial nessas coisas também, apenas indicando sua existência e fazendo um ou outro comentário -- não entro nos detalhes porque não cabe aqui, e porque cuidar dos detalhes é justamente o que o seu projeto se propõe a fazer. Além disso, eu indico a declaração de várias classes diferentes como se estivessem num arquivo só. Na implementação real, você poderia partir em vários arquivos de cabeçalhos diferentes.(2) Eu coloco código no próprio cabeçalho, para que ele fique inline (nesse caso, não é nem mesmo necessário usar a palavra-chave inline ). Isso é interessante numa biblioteca que é para ser só uma casquinha em cima da implementação em C e que é voltada para aplicações que tipicamente precisam do melhor desempenho possível. Por outro lado, ter código no cabeçalho faz a compilação mais lenta do que seria se houvesse apenas declarações (o que acaba sendo mais um argumento em favor de separar cada classe ou pequeno grupo de classes correlatas em cabeçalhos diferentes).(3) Eu posso ter feito alguma (ou muita) bobagem neste exemplo, de modo que você pode e deve corrigir meus erros -- até porque tudo nesta postagem é sugestão especulativa.
// th_sdl.h
Um problema de ter, agora, um monte de exceções voando pelo código é que pode ser que algum recurso importante alocado pela SDL fique sem ser devidamente devolvido ao sistema se o usuário esquecer de capturar uma dessas exceções.
Corriqueiramente, aplicações com SDL costumam usar
atexit () do C para implicar uma chamada a
SDL_Quit () antes de a aplicação terminar, mas as funções registradas dessa maneira não são executadas em caso de chamada a
abort () do C nem a
std::terminate (), que são usadas quando se dispara uma exceção que não é capturada.
Uma abordagem típ
ica de frameworks para aplicações C++ é você definir uma classe para representar a aplicação, e supor (ou induzir a) que todas as aplicações com esse framework derivem dessa classe. No seu caso, isso poderia ficar mais ou menos com a seguinte forma.
// th_sdlapp.h
// th_sdlapp.cc
O fato do método
run () ter um tratamento
default de exceções não o impede de dar um tratamento mais especializado no método
exec () que você há de implementar na classe derivada que representará a aplicação, nem em outras funções que forem invocadas por sua implementação. Os tratadores
default são apenas uma salvaguarda para tentar garantir que uma exceção não “vaze” até
main (), a fim de garantir que o destrutor da aplicação, que vai desalocar os recursos da SDL, seja efetivamente chamado.
Dito de outra forma, o que se tenta fazer é fazer com que toda a aplicação envelope o uso de recursos da SDL com a técnica de RAII (
Resource Acquisition Is Initialization ), que é a técnica favorita de gestão de recursos em C++. Ao trazer toda a aquisição de recursos para o construtor e a sua correspondente liberação para o destrutor (de certo modo complicando a implementação da classe), o usuário da classe tem de empreender muito menos esforço (e, consequentemente, fica menos sujeito a cometer erros) para manter tais recursos por conta própria. RAII é o princípio que permeia o projeto da STL (
Standard Template Library , que é parte da biblioteca padrão do C++),
smart pointers , e também bibliotecas de terceiros voltadas para C++, como Boost, Qt, e muitas outras.
Para usar RAII, e particularmente uma classe derivada da
sdl::application apresentada acima, a aplicação tem de tomar alguns cuidados. Um deles é nunca chamar
std::exit (), nem tampouco
std::abort ou
std::terminate , em nenhuma parte do seu código nem em código de terceiros que você vier a usar. A razão é simples:
std::exit () tipicamente desvia o fluxo de execução para um ponto posterior ao final da função
main (), passando ao largo do código gerado pelo compilador para invocar os destrutores de objetos criados localmente por qualquer função, inclusive a própria
main (). Os únicos objetos cujos destrutores são chamados quando se chama
std::exit () são aqueles que tenham sido construídos estaticamente, antes da execução de
main (). Já
std::terminate () e
std::abort () normalmente não desconstroem nem mesmo esses objetos estáticos. Assim sendo, você precisa garantir que as únicas possibilidades de você terminar a execução do método
exec () que você implementar são por meio de um comando
return dentro do corpo do método, ou através do disparo de uma exceção, que pode ser feito por ele mesmo ou por qualquer função por ele chamada, uma vez que o método
run () tem tratadores para todas as possibilidades de exceções.
(Você pode até tentar criar algumas caixas pretas para aceitar alguns casos de uso de
std::exit () e com uma declaração do objeto da aplicação como global, mas isso será uma hackeada meio suja e trabalhosa. Não acho que valha o esforço -- é mais fácil, e muito mais limpo, adequar-se ao uso de RAII.)
Sabendo tudo isso, eis como a aplicação poderia ser construída.
// my_sdl_app.h
// my_sdl_app.cc
// main.cc
Bom, já dei palpite demais. De novo, desejo sucesso ao projeto.
