É uma boa ideia aplicar algumas macros básicas para simplificar o código em um projeto grande?

8

Eu tenho trabalhado em uma biblioteca de c ++ por algum tempo e há uma variedade de idéias que eu poderia realmente simplificar o processo de escrita e gerenciamento de código. Um deles é o conceito de introduzir algumas macros para ajudar a simplificar as declarações que aparecem com muita frequência, mas são um pouco mais complicadas do que deveriam ser necessárias.

Por exemplo, eu criei essa macro básica para simplificar o tipo mais comum de loop:

#define loop(v,n) for(unsigned long v=0; v<n; ++v)

Isso permitiria que você substituísse os loops desajeitados pelos quais você vê muito:

for (int i = 0; i < max_things; i++)

Com algo muito mais fácil de escrever e até mesmo um pouco mais eficiente:

loop (i, max_things)

É uma boa ideia usar convenções como essa? Há algum problema que você possa encontrar com diferentes tipos de compiladores? Seria apenas confuso demais para alguém não familiarizado com a macro (s)?

    
por Tim Leaf 20.04.2010 в 18:47
fonte

9 respostas

26

IMHO isso geralmente é uma má ideia. Você está essencialmente mudando a sintaxe bem conhecida e compreendida para algo de sua própria invenção. Em pouco tempo você pode descobrir que você reinventou o idioma . :)

    
por dkackman 20.04.2010 / 18:50
fonte
2

Não, não é uma boa ideia.


  int max = 23;
  loop(i, ++max)...

É, no entanto, uma boa ideia refatorar o código comumente usado em componentes reutilizáveis e reutilizá-lo em vez de copiá-lo. Você deve fazer isso escrevendo funções similares aos algoritmos padrão como std :: find (). Por exemplo:


template < typename Function >
void loop(size_t count, Function f)
{
  for (size_t i = 0; i < count, ++i) f();
}

Esta é uma abordagem muito mais segura:


int max = 23;
loop(++max, boost::bind(....));
    
por Crazy Eddie 20.04.2010 / 19:00
fonte
2

Acho que você forneceu um argumento forte contra essa macro com seu uso de exemplo. Você alterou o tipo de iterador de loop de int para unsigned long . Isso não tem nada a ver com quanta digitação você quer fazer, então por que mudar isso?

Esse incômodo para o loop especifica o valor inicial, o valor final, o tipo e o nome do iterador. Mesmo se assumirmos que a parte final será sempre ++name , e estamos felizes em manter isso, você tem duas opções - remover um pouco da flexibilidade ou digitar tudo o tempo todo. Você optou por remover a flexibilidade, mas também parece estar usando essa flexibilidade em sua base de código.

    
por Steve Jessop 20.04.2010 / 19:07
fonte
2

Eu diria que depende se você espera que alguém mais tenha algum sentido em seu código. Se é só você vai estar lá, então eu não vejo um problema com as macros.

Se qualquer outra pessoa precisar examinar esse código, as macros causarão problemas. A outra pessoa não saberá o que é ou o que faz (não importa quão legível e óbvio lhe pareça) e terá que caçá-la quando a encontrar pela primeira vez. O resultado será tornar seu código ilegível para qualquer pessoa, exceto você mesmo - qualquer um que o utilize essencialmente terá que aprender um novo idioma e um programa ao mesmo tempo.

E como as chances de você simplesmente lidar com o código são praticamente nulas se você espera que o código seja uma biblioteca que será mais do que apenas o seu uso pessoal - então eu vou com don 't .

    
por Daniel Bingham 20.04.2010 / 18:50
fonte
2

No Unix, acho que quando eu quero criar um alias para um comando que uso o tempo todo, o comando está em meus dedos, e eu teria mais dificuldade em lembrar a sintaxe do meu alias do que o comando original.

O mesmo se aplica aqui - no momento em que você usa um idioma que você quer criar uma macro para ele, o idioma estará nos dedos e causará mais dor do que apenas digitar o código.

    
por JohnMcG 20.04.2010 / 19:46
fonte
1

Livrar-se dos loops for geralmente é uma boa ideia - mas substituí-los por macros não é. Eu daria uma olhada longa e difícil nos algoritmos da biblioteca padrão.

    
por Jerry Coffin 20.04.2010 / 18:56
fonte
0

Além dos problemas de manutenção / compreensão mencionados por outros, você também terá dificuldade em dividir e passar por um código de macro.

Uma área onde eu acho que macros podem ser aceitáveis seria para preencher grandes estruturas de dados com constantes / litterals (quando ele pode economizar uma quantidade excessiva de digitação). Você normalmente não passaria por esse código.

    
por Emile Cormier 20.04.2010 / 19:19
fonte
0

Steve Jessop faz um bom argumento. Macros têm seus usos. Se eu puder expor suas declarações, eu diria que o argumento a favor ou contra as macros se resume a "depende". Se você fizer suas macros sem pensar cuidadosamente, corre o risco de dificultar as vidas dos futuros mantenedores. Por outro lado, usar a biblioteca wxWidgets requer o uso de macros fornecidas pela biblioteca para conectar seu código com a biblioteca GUI. Nesse caso, as macros diminuem a barreira de entrada para o uso da biblioteca, pois a magia cujas entranhas são irrelevantes para entender como trabalhar com a biblioteca fica oculta do usuário. Nesse caso, o usuário é salvo de ter que entender coisas que realmente não precisa saber e pode-se argumentar que esse é um uso "Bom" de macros. Além disso, o wxWidgets documenta claramente como essas macros devem ser usadas. Portanto, certifique-se de que o que você esconde não seja algo que precise ser entendido por outra pessoa que esteja chegando.

Ou, se for apenas para o seu uso, se mate.

    
por Joshua 20.04.2010 / 19:14
fonte
0

É uma questão de onde você está obtendo seu valor. Está digitando esses 15 caracteres extras em seus loops realmente, o que está atrasando seu desenvolvimento? Provavelmente não. Se você tem múltiplas linhas de clichê confuso e inevitável aparecendo em todo o lugar, então você pode e deve procurar maneiras de evitar se repetir, como criar funções úteis, limpar suas hierarquias de classes ou usar modelos.

Mas as mesmas regras de otimização aplicam-se a escrever código para executá-lo: otimizar pequenas coisas com pouco efeito não é realmente um bom uso de tempo ou energia.

    
por Ipsquiggle 20.04.2010 / 18:57
fonte