Quando as macros C ++ são benéficas? [fechadas]

o pré-processador C é justificadamente temido e evitado pela comunidade C ++. Funções alinhadas, consts e modelos são geralmente uma alternativa mais segura e superior a a #define.

A seguinte macro:

#define SUCCEEDED(hr) ((HRESULT)(hr) >= 0)  

não é de forma alguma superior ao tipo seguro:

inline bool succeeded(int hr) { return hr >= 0; }

Mas as macros têm seu lugar, liste os usos que você encontra para as macros que você não pode fazer sem o pré-processador.

Coloque cada caso de uso em uma resposta separada para que possa ser votado e, se você souber como obter uma das respostas sem o pré-professor, aponte como nos comentários dessa resposta.

Como wrappers para as funções de depuração, para passar automaticamente coisas como __FILE__, __LINE__, etc:

#ifdef ( DEBUG )
#define M_DebugLog( msg )  std::cout << __FILE__ << ":" << __LINE__ << ": " << msg
#else
#define M_DebugLog( msg )
#endif

Os métodos sempre devem ser códigos completos e compiláveis; macros podem ser fragmentos de código. Assim, você pode definir uma macro foreach:

#define foreach(list, index) for(index = 0; index < list.size(); index++)

E use-o da seguinte maneira:

foreach(cookies, i)
    printf("Cookie: %s", cookies[i]);

Desde o C ++ 11, isso é substituído pelo loop for baseado em intervalo .

Os protetores de arquivo de cabeçalho precisam de macros.

Existem outras áreas que precisam de macros? Não são muitos (se houver).

Existem outras situações que se beneficiam de macros? SIM!!!

Um lugar que eu uso macros é com código muito repetitivo. Por exemplo, ao agrupar o código C ++ para ser usado com outras interfaces (.NET, COM, Python, etc ...), preciso capturar diferentes tipos de exceções. Aqui está como eu faço isso:

#define HANDLE_EXCEPTIONS \
catch (::mylib::exception& e) { \
    throw gcnew MyDotNetLib::Exception(e); \
} \
catch (::std::exception& e) { \
    throw gcnew MyDotNetLib::Exception(e, __LINE__, __FILE__); \
} \
catch (...) { \
    throw gcnew MyDotNetLib::UnknownException(__LINE__, __FILE__); \
}

Eu tenho que colocar essas capturas em todas as funções do invólucro. Em vez de digitar todos os blocos de captura completos, basta digitar:

void Foo()
{
    try {
        ::mylib::Foo()
    }
    HANDLE_EXCEPTIONS
}

Isso também facilita a manutenção. Se eu tiver que adicionar um novo tipo de exceção, há apenas um lugar em que preciso adicioná-lo.

Também existem outros exemplos úteis: muitos deles incluem as macros __FILE__e __LINE__pré - processador.

De qualquer forma, as macros são muito úteis quando usadas corretamente. Macros não são más - seu mau uso é mau.

Na maioria das vezes:

1. Incluir guardas
2. Compilação condicional
3. Relatórios (macros predefinidas como __LINE__e __FILE__)
4. (raramente) Duplicar padrões de código repetitivo.
5. No código do seu concorrente.

Compilação condicional interna, para superar problemas de diferenças entre compiladores:

#ifdef ARE_WE_ON_WIN32
#define close(parm1)            _close (parm1)
#define rmdir(parm1)            _rmdir (parm1)
#define mkdir(parm1, parm2)     _mkdir (parm1)
#define access(parm1, parm2)    _access(parm1, parm2)
#define create(parm1, parm2)    _creat (parm1, parm2)
#define unlink(parm1)           _unlink(parm1)
#endif

Quando você deseja transformar uma string em uma expressão, o melhor exemplo disso é assert( #xtransforma o valor de xem uma string).

#define ASSERT_THROW(condition) \
if (!(condition)) \
     throw std::exception(#condition " is false");

Às vezes, as constantes de string são melhor definidas como macros, pois você pode fazer mais com literais de string do que com a const char *.

por exemplo, literais de string podem ser facilmente concatenados .

#define BASE_HKEY "Software\\Microsoft\\Internet Explorer\\"
// Now we can concat with other literals
RegOpenKey(HKEY_CURRENT_USER, BASE_HKEY "Settings", &settings);
RegOpenKey(HKEY_CURRENT_USER, BASE_HKEY "TypedURLs", &URLs);

Se a const char *fosse usado, algum tipo de classe de cadeia teria que ser usada para executar a concatenação no tempo de execução:

const char* BaseHkey = "Software\\Microsoft\\Internet Explorer\\";
RegOpenKey(HKEY_CURRENT_USER, (string(BaseHkey) + "Settings").c_str(), &settings);
RegOpenKey(HKEY_CURRENT_USER, (string(BaseHkey) + "TypedURLs").c_str(), &URLs);

Quando você deseja alterar o código de fluxo do programa ( return, breake continue) em uma função se comporta de maneira diferente do código realmente embutido na função.

#define ASSERT_RETURN(condition, ret_val) \
if (!(condition)) { \
    assert(false && #condition); \
    return ret_val; }

// should really be in a do { } while(false) but that's another discussion.

O óbvio inclui guardas

#ifndef MYHEADER_H
#define MYHEADER_H

...

#endif

Você não pode executar um curto-circuito nos argumentos de chamada de função usando uma chamada de função regular. Por exemplo:

#define andm(a, b) (a) && (b)

bool andf(bool a, bool b) { return a && b; }

andm(x, y) // short circuits the operator so if x is false, y would not be evaluated
andf(x, y) // y will always be evaluated

Digamos que ignoraremos coisas óbvias, como guardas de cabeçalho.

Às vezes, você deseja gerar código que precisa ser copiado / colado pelo pré-compilador:

#define RAISE_ERROR_STL(p_strMessage)                                          \
do                                                                             \
{                                                                              \
   try                                                                         \
   {                                                                           \
      std::tstringstream strBuffer ;                                           \
      strBuffer << p_strMessage ;                                              \
      strMessage = strBuffer.str() ;                                           \
      raiseSomeAlert(__FILE__, __FUNCSIG__, __LINE__, strBuffer.str().c_str()) \
   }                                                                           \
   catch(...){}                                                                \
   {                                                                           \
   }                                                                           \
}                                                                              \
while(false)

que permite codificar isso:

RAISE_ERROR_STL("Hello... The following values " << i << " and " << j << " are wrong") ;

E pode gerar mensagens como:

Error Raised:
====================================
File : MyFile.cpp, line 225
Function : MyFunction(int, double)
Message : "Hello... The following values 23 and 12 are wrong"

Observe que a mistura de modelos com macros pode levar a resultados ainda melhores (ou seja, gerar automaticamente os valores lado a lado com seus nomes de variáveis)

Outras vezes, você precisa do __FILE__ e / ou __LINE__ de algum código, para gerar informações de depuração, por exemplo. A seguir, é um clássico do Visual C ++:

#define WRNG_PRIVATE_STR2(z) #z
#define WRNG_PRIVATE_STR1(x) WRNG_PRIVATE_STR2(x)
#define WRNG __FILE__ "("WRNG_PRIVATE_STR1(__LINE__)") : ------------ : "

Como no código a seguir:

#pragma message(WRNG "Hello World")

gera mensagens como:

C:\my_project\my_cpp_file.cpp (225) : ------------ Hello World

Outras vezes, você precisa gerar código usando os operadores de concatenação # e ##, como gerar getters e setters para uma propriedade (isso é para casos bastante limitados).

Outras vezes, você irá gerar código que não será compilado se usado por meio de uma função, como:

#define MY_TRY      try{
#define MY_CATCH    } catch(...) {
#define MY_END_TRY  }

Qual pode ser usado como

MY_TRY
   doSomethingDangerous() ;
MY_CATCH
   tryToRecoverEvenWithoutMeaningfullInfo() ;
   damnThoseMacros() ;
MY_END_TRY

(ainda assim, eu só vi esse tipo de código usado corretamente uma vez )

Por último, mas não menos importante, o famoso boost::foreach!!!

#include <string>
#include <iostream>
#include <boost/foreach.hpp>

int main()
{
    std::string hello( "Hello, world!" );

    BOOST_FOREACH( char ch, hello )
    {
        std::cout << ch;
    }

    return 0;
}

(Nota: cópia de código / colada na página inicial do impulso)

Qual é (IMHO) muito melhor do que std::for_each.

Portanto, as macros são sempre úteis porque estão fora das regras normais do compilador. Mas acho que na maioria das vezes vejo um, eles são efetivamente restos do código C nunca convertidos em C ++ apropriado.

As estruturas de teste de unidade para C ++, como o UnitTest ++, giram em torno das macros do pré-processador. Algumas linhas de código de teste de unidade se expandem para uma hierarquia de classes que não seria divertido digitar manualmente. Sem algo como o UnitTest ++ e a mágica do pré-processador, não sei como você escreveria testes de unidade para C ++ com eficiência.

Temer o pré-processador C é como temer as lâmpadas incandescentes apenas porque temos lâmpadas fluorescentes. Sim, o primeiro pode ser {eletricidade | tempo do programador} ineficiente. Sim, você pode se queimar (literalmente) por eles. Mas eles podem fazer o trabalho se você lidar com isso adequadamente.

Quando você programa sistemas incorporados, C costuma ser a única opção além do montador de formulários. Depois de programar na área de trabalho com C ++ e depois mudar para destinos menores e incorporados, você aprende a parar de se preocupar com “deselegâncias” de tantos recursos simples de C (incluindo macros) e apenas tentando descobrir o melhor e seguro uso que você pode obter daqueles recursos.

Alexander Stepanov diz :

Quando programamos em C ++, não devemos ter vergonha de sua herança C, mas fazer pleno uso dela. Os únicos problemas com C ++, e mesmo os únicos problemas com C, surgem quando eles próprios não são consistentes com sua própria lógica.

Usamos as macros __FILE__e __LINE__para fins de diagnóstico em lançamentos, capturas e registros de exceções ricas em informações, juntamente com scanners de arquivos de log automatizados em nossa infraestrutura de controle de qualidade.

Por exemplo, uma macro de lançamento OUR_OWN_THROWpode ser usada com parâmetros de tipo e construtor de exceção para essa exceção, incluindo uma descrição textual. Como isso:

OUR_OWN_THROW(InvalidOperationException, (L"Uninitialized foo!"));

Obviamente, essa macro lançará a InvalidOperationExceptionexceção com a descrição como parâmetro construtor, mas também gravará uma mensagem em um arquivo de log que consiste no nome do arquivo e no número da linha em que a ocorrência ocorreu e sua descrição textual. A exceção lançada receberá um ID, que também será registrado. Se a exceção for capturada em algum outro lugar do código, ela será marcada como tal e o arquivo de log indicará que essa exceção específica foi tratada e, portanto, não é provável que seja a causa de qualquer falha que possa ser registrada posteriormente. Exceções não tratadas podem ser facilmente detectadas por nossa infraestrutura automatizada de controle de qualidade.

Repetição de código.

Dê uma olhada para aumentar a biblioteca de pré-processadores , é um tipo de meta-meta-programação. No tópico motivação, você pode encontrar um bom exemplo.

Alguns itens muito avançados e úteis ainda podem ser criados usando pré-processador (macros), o que você nunca seria capaz de fazer usando as "construções de linguagem" do c ++, incluindo modelos.

Exemplos:

Fazendo algo tanto um identificador C quanto uma string

Maneira fácil de usar variáveis ​​de tipos de enumeração como string em C

Aumentar a metaprogramação do pré-processador

Ocasionalmente, uso macros para definir informações em um único local, mas de diferentes maneiras em diferentes partes do código. É apenas um pouco mal :)

Por exemplo, em "field_list.h":

/*
 * List of fields, names and values.
 */
FIELD(EXAMPLE1, "first example", 10)
FIELD(EXAMPLE2, "second example", 96)
FIELD(ANOTHER, "more stuff", 32)
...
#undef FIELD

Em seguida, para uma enumeração pública, pode ser definido apenas para usar o nome:

#define FIELD(name, desc, value) FIELD_ ## name,

typedef field_ {

#include "field_list.h"

    FIELD_MAX

} field_en;

E em uma função init privada, todos os campos podem ser usados ​​para preencher uma tabela com os dados:

#define FIELD(name, desc, value) \
    table[FIELD_ ## name].desc = desc; \
    table[FIELD_ ## name].value = value;

#include "field_list.h"

Um uso comum é para detectar o ambiente de compilação; para o desenvolvimento de plataforma cruzada, você pode escrever um conjunto de códigos para o Linux, por exemplo, e outro para o Windows, quando ainda não existe uma biblioteca de plataforma cruzada para seus propósitos.

Portanto, em um exemplo aproximado, um mutex de plataforma cruzada pode ter

void lock()
{
    #ifdef WIN32
    EnterCriticalSection(...)
    #endif
    #ifdef POSIX
    pthread_mutex_lock(...)
    #endif
}

Para funções, elas são úteis quando você deseja ignorar explicitamente a segurança de tipo. Como os muitos exemplos acima e abaixo para fazer ASSERT. Obviamente, como muitos recursos do C / C ++, você pode dar um tiro no pé, mas a linguagem fornece as ferramentas e permite que você decida o que fazer.

Algo como

void debugAssert(bool val, const char* file, int lineNumber);
#define assert(x) debugAssert(x,__FILE__,__LINE__);

Para que você possa, por exemplo, ter

assert(n == true);

e obtenha o nome do arquivo de origem e o número da linha do problema impressos em seu log, se n for falso.

Se você usar uma chamada de função normal, como

void assert(bool val);

em vez da macro, tudo o que você pode obter é o número da linha da sua função assert impressa no log, o que seria menos útil.

#define ARRAY_SIZE(arr) (sizeof arr / sizeof arr[0])

Diferente da solução de modelo 'preferencial' discutida em um encadeamento atual, você pode usá-lo como uma expressão constante:

char src[23];
int dest[ARRAY_SIZE(src)];

Você pode usar #defines para ajudar nos cenários de depuração e teste de unidade. Por exemplo, crie variantes de log especiais das funções de memória e crie um memlog_preinclude.h especial:

#define malloc memlog_malloc
#define calloc memlog calloc
#define free memlog_free

Compile seu código usando:

gcc -Imemlog_preinclude.h ...

Um link no seu memlog.o para a imagem final. Agora você controla malloc, etc., talvez para fins de registro ou para simular falhas de alocação para testes de unidade.

Quando você está tomando uma decisão em tempo de compilação sobre o comportamento específico do Compiler / OS / Hardware.

Ele permite que você faça sua interface com os recursos específicos do Comppiler / OS / Hardware.

#if defined(MY_OS1) && defined(MY_HARDWARE1)
#define   MY_ACTION(a,b,c)      doSothing_OS1HW1(a,b,c);}
#elif define(MY_OS1) && defined(MY_HARDWARE2)
#define   MY_ACTION(a,b,c)      doSomthing_OS1HW2(a,b,c);}
#elif define(MY_SUPER_OS)
          /* On this hardware it is a null operation */
#define   MY_ACTION(a,b,c)
#else
#error  "PLEASE DEFINE MY_ACTION() for this Compiler/OS/HArdware configuration"
#endif

Eu uso macros para definir facilmente exceções:

DEF_EXCEPTION(RessourceNotFound, "Ressource not found")

onde DEF_EXCEPTION é

#define DEF_EXCEPTION(A, B) class A : public exception\
  {\
  public:\
    virtual const char* what() const throw()\
    {\
      return B;\
    };\
  }\

Os compiladores podem recusar sua solicitação para incorporar.

As macros sempre terão seu lugar.

Algo que acho útil é #define DEBUG para rastreamento de depuração - você pode deixá-lo 1 durante a depuração de um problema (ou até deixá-lo ligado durante todo o ciclo de desenvolvimento) e depois desativá-lo na hora de enviar.

No meu último trabalho, eu estava trabalhando em um antivírus. Para facilitar a depuração, eu tinha muitos logs presos em todo o lugar, mas em um aplicativo de alta demanda como esse, a despesa de uma chamada de função é muito cara. Então, eu criei essa pequena macro, que ainda me permitia ativar o log de depuração em uma versão de lançamento no site de clientes, sem o custo de uma chamada de função verificaria o sinalizador de depuração e retornaria sem registrar nada, ou se ativado , faria o log ... A macro foi definida da seguinte maneira:

#define dbgmsg(_FORMAT, ...)  if((debugmsg_flag  & 0x00000001) || (debugmsg_flag & 0x80000000))     { log_dbgmsg(_FORMAT, __VA_ARGS__);  }

Devido ao VA_ARGS nas funções de log, esse era um bom caso para uma macro como essa.

Antes disso, eu usava uma macro em um aplicativo de alta segurança que precisava dizer ao usuário que eles não tinham o acesso correto e que tipo de sinalizador eles precisavam.

As macro (s) definidas como:

#define SECURITY_CHECK(lRequiredSecRoles) if(!DoSecurityCheck(lRequiredSecRoles, #lRequiredSecRoles, true)) return
#define SECURITY_CHECK_QUIET(lRequiredSecRoles) (DoSecurityCheck(lRequiredSecRoles, #lRequiredSecRoles, false))

Em seguida, poderíamos simplesmente espalhar as verificações por toda a interface do usuário, e ele informaria quais funções tinham permissão para executar a ação que você tentou executar, se você ainda não tivesse essa função. A razão para dois deles foi retornar um valor em alguns lugares e retornar de uma função nula em outros ...

SECURITY_CHECK(ROLE_BUSINESS_INFORMATION_STEWARD | ROLE_WORKER_ADMINISTRATOR);

LRESULT CAddPerson1::OnWizardNext() 
{
   if(m_Role.GetItemData(m_Role.GetCurSel()) == parent->ROLE_EMPLOYEE) {
      SECURITY_CHECK(ROLE_WORKER_ADMINISTRATOR | ROLE_BUSINESS_INFORMATION_STEWARD ) -1;
   } else if(m_Role.GetItemData(m_Role.GetCurSel()) == parent->ROLE_CONTINGENT) {
      SECURITY_CHECK(ROLE_CONTINGENT_WORKER_ADMINISTRATOR | ROLE_BUSINESS_INFORMATION_STEWARD | ROLE_WORKER_ADMINISTRATOR) -1;
   }
...

De qualquer forma, foi assim que os usei e não tenho certeza de como isso poderia ter sido ajudado com modelos ... Fora isso, tento evitá-los, a menos que seja realmente necessário.

Mais uma macros foreach. T: tipo, c: contêiner, i: iterador

#define foreach(T, c, i) for(T::iterator i=(c).begin(); i!=(c).end(); ++i)
#define foreach_const(T, c, i) for(T::const_iterator i=(c).begin(); i!=(c).end(); ++i)

Uso (exibição de conceito, não real):

void MultiplyEveryElementInList(std::list<int>& ints, int mul)
{
    foreach(std::list<int>, ints, i)
        (*i) *= mul;
}

int GetSumOfList(const std::list<int>& ints)
{
    int ret = 0;
    foreach_const(std::list<int>, ints, i)
        ret += *i;
    return ret;
}

Melhores implementações disponíveis: Google "BOOST_FOREACH"

Bons artigos disponíveis: Amor condicional: FOREACH Redux (Eric Niebler) http://www.artima.com/cppsource/foreach.html

Talvez o ótimo uso das macros esteja no desenvolvimento independente da plataforma. Pense em casos de inconsistência de tipo - com macros, você pode simplesmente usar diferentes arquivos de cabeçalho - como: --WIN_TYPES.H

typedef ...some struct

--POSIX_TYPES.h

typedef ...some another struct

--program.h

#ifdef WIN32
#define TYPES_H "WINTYPES.H"
#else 
#define TYPES_H "POSIX_TYPES.H"
#endif

#include TYPES_H

Muito legível do que implementá-lo de outras maneiras, na minha opinião.

Parece que VA_ARGS só foi mencionado indiretamente até agora:

Ao escrever código C ++ 03 genérico e você precisa de um número variável de parâmetros (genéricos), pode usar uma macro em vez de um modelo.

#define CALL_RETURN_WRAPPER(FnType, FName, ...)          \
  if( FnType theFunction = get_op_from_name(FName) ) {   \
    return theFunction(__VA_ARGS__);                     \
  } else {                                               \
    throw invalid_function_name(FName);                  \
  }                                                      \
/**/

_{Nota: Em geral, o nome check / throw também pode ser incorporado na hipóteseget_op_from_name função . Este é apenas um exemplo. Pode haver outro código genérico ao redor da chamada VA_ARGS.}

Depois de obtermos modelos variados com o C ++ 11, podemos resolver isso "corretamente" com um modelo.

Eu acho que esse truque é um uso inteligente do pré-processador que não pode ser emulado com uma função:

#define COMMENT COMMENT_SLASH(/)
#define COMMENT_SLASH(s) /##s

#if defined _DEBUG
#define DEBUG_ONLY
#else
#define DEBUG_ONLY COMMENT
#endif

Então você pode usá-lo assim:

cout <<"Hello, World!" <<endl;
DEBUG_ONLY cout <<"This is outputed only in debug mode" <<endl;

Você também pode definir uma macro RELEASE_ONLY.

Você pode #defineconstantes na linha de comando do compilador usando a opção -Dou /DIsso geralmente é útil na compilação cruzada do mesmo software para várias plataformas, porque você pode fazer com que seus makefiles controlem quais constantes são definidas para cada plataforma.