Quando sono utili le macro C ++? [chiuso]

Il preprocessore C è giustamente temuto e evitato dalla comunità C ++. Le funzioni, i cons e i template integrati sono in genere un'alternativa più sicura e superiore a a #define.

La seguente macro:

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

non è in alcun modo superiore al tipo sicuro:

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

Ma le macro hanno il loro posto, ti preghiamo di elencare gli usi che trovi per le macro che non puoi fare a meno del preprocessore.

Si prega di inserire ogni caso d'uso in una risposta separata in modo che possa essere votato e se si sa come ottenere una delle risposte senza il pre-predecessore, indicare come nei commenti di quella risposta.

Come wrapper per funzioni di debug, per passare automaticamente le cose come __FILE__, __LINE__, ecc:

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

I metodi devono essere sempre completi, codice compilabile; le macro possono essere frammenti di codice. Quindi puoi definire una macro foreach:

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

E usalo così:

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

Dal C ++ 11, questo è sostituito dal basato su loop per .

Le protezioni dei file di intestazione richiedono macro.

Ci sono altre aree che richiedono macro? Non molti (se presenti).

Ci sono altre situazioni che beneficiano delle macro? SÌ!!!

Un posto in cui uso le macro è con un codice molto ripetitivo. Ad esempio, quando si esegue il wrapping del codice C ++ da utilizzare con altre interfacce (.NET, COM, Python, ecc ...), è necessario rilevare diversi tipi di eccezioni. Ecco come lo faccio:

#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__); \
}

Devo mettere queste catture in ogni funzione wrapper. Invece di digitare ogni volta i blocchi di cattura completi, scrivo solo:

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

Ciò semplifica anche la manutenzione. Se dovessi mai aggiungere un nuovo tipo di eccezione, c'è solo un posto in cui devo aggiungerlo.

Ci sono anche altri esempi utili: molti dei quali includono le macro __FILE__e il __LINE__preprocessore.

Comunque, le macro sono molto utili se usate correttamente. Le macro non sono cattive - il loro uso improprio è malvagio.

Soprattutto:

1. Includi le protezioni
2. Compilazione condizionale
3. Rapporti (macro predefinite come __LINE__e __FILE__)
4. (raramente) Duplicazione di schemi di codice ripetitivi.
5. Nel codice del tuo concorrente.

All'interno della compilazione condizionale, per superare i problemi di differenze tra compilatori:

#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 si desidera creare una stringa da un'espressione, l'esempio migliore è assert( #xtrasforma il valore xin una stringa).

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

Le costanti di stringa sono talvolta meglio definite come macro poiché puoi fare di più con i letterali di stringa che con a const char *.

ad es. i letterali stringa possono essere facilmente concatenati .

#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 const char *fosse usato un, allora una sorta di classe stringa dovrebbe essere usata per eseguire la concatenazione in fase di esecuzione:

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 si desidera modificare il flusso del programma ( return, breake continue) il codice in una funzione si comporta in modo diverso rispetto al codice effettivamente incorporato nella funzione.

#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.

L'ovvio include le guardie

#ifndef MYHEADER_H
#define MYHEADER_H

...

#endif

Non è possibile eseguire il cortocircuito degli argomenti della chiamata di funzione utilizzando una normale chiamata di funzione. Per esempio:

#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

Diciamo che ignoreremo cose ovvie come le protezioni per i colpi di testa.

A volte, si desidera generare il codice che deve essere copiato / incollato dal precompilatore:

#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)

che ti consente di codificare questo:

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

E può generare messaggi come:

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

Si noti che la combinazione di modelli con macro può portare a risultati ancora migliori (ovvero generare automaticamente i valori fianco a fianco con i loro nomi variabili)

Altre volte, per generare informazioni di debug, ad esempio, è necessario __FILE__ e / o __LINE__ di alcuni codici. Di seguito è un classico per Visual C ++:

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

Come con il seguente codice:

#pragma message(WRNG "Hello World")

genera messaggi come:

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

Altre volte, è necessario generare codice utilizzando gli operatori di concatenazione # e ##, come la generazione di getter e setter per una proprietà (ciò avviene in casi piuttosto limitati, attraverso).

Altre volte, genererai codice che non verrà compilato se utilizzato tramite una funzione, come:

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

Quale può essere usato come

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

(comunque, ho visto solo questo tipo di codice usato correttamente una volta )

Ultimo, ma non meno importante, il 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: copia del codice / incollato dalla home page boost)

Quale è (IMHO) molto meglio di std::for_each.

Quindi, le macro sono sempre utili perché sono al di fuori delle normali regole del compilatore. Ma trovo che la maggior parte delle volte che ne vedo uno, sono effettivamente resti di codice C mai tradotti in C ++ corretto.

I framework di unit test per C ++ come UnitTest ++ ruotano praticamente attorno a macro di preprocessore. Alcune righe di codice unit test si espandono in una gerarchia di classi che non sarebbe affatto divertente digitare manualmente. Senza qualcosa come UnitTest ++ e la sua magia preprocessore, non so come scriveresti in modo efficiente unit test per C ++.

Temere il preprocessore C è come temere le lampadine a incandescenza solo perché otteniamo lampadine fluorescenti. Sì, il primo può essere {elettricità | tempo del programmatore} inefficiente. Sì, puoi essere (letteralmente) bruciato da loro. Ma possono fare il lavoro se lo gestisci correttamente.

Quando si programmano i sistemi incorporati, C è l'unica opzione a parte l'assemblatore di moduli. Dopo aver programmato sul desktop con C ++ e poi passato a target integrati più piccoli, impari a smettere di preoccuparti delle "ineleganze" di così tante funzionalità C nude (macro incluse) e solo di cercare di capire l'uso migliore e sicuro che puoi ottenere da quelle Caratteristiche.

Alexander Stepanov dice :

Quando programmiamo in C ++ non dovremmo vergognarci del suo patrimonio in C, ma sfruttarlo appieno. Gli unici problemi con C ++ e anche gli unici problemi con C sorgono quando essi stessi non sono coerenti con la propria logica.

Utilizziamo macro __FILE__e __LINE__a scopo diagnostico per generare, intercettare e registrare eccezioni ricche di informazioni, insieme a scanner automatici di file di registro nella nostra infrastruttura di controllo qualità.

Ad esempio, una macro di lancio OUR_OWN_THROWpotrebbe essere utilizzata con il tipo di eccezione e i parametri del costruttore per tale eccezione, inclusa una descrizione testuale. Come questo:

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

Questa macro genererà ovviamente l' InvalidOperationExceptioneccezione con la descrizione come parametro del costruttore, ma scriverà anche un messaggio in un file di registro costituito dal nome del file e dal numero di riga in cui si è verificato il lancio e dalla sua descrizione testuale. L'eccezione generata otterrà un ID, che viene anche registrato. Se l'eccezione viene rilevata da qualche altra parte nel codice, verrà contrassegnata come tale e il file di registro indicherà quindi che l'eccezione specifica è stata gestita e che pertanto non è probabile che sia la causa di un arresto anomalo che potrebbe essere registrato in un secondo momento. Le eccezioni non gestite possono essere facilmente rilevate dalla nostra infrastruttura di controllo qualità automatizzata.

Ripetizione del codice.

Dai un'occhiata per potenziare la libreria dei preprocessori , è una sorta di meta-meta-programmazione. Nell'argomento-> motivazione puoi trovare un buon esempio.

Alcune cose molto avanzate e utili possono ancora essere costruite usando il preprocessore (macro), che non saresti mai in grado di fare usando i "costrutti del linguaggio" c ++ inclusi i template.

Esempi:

Fare qualcosa sia un identificatore C che una stringa

Modo semplice per usare variabili di tipo enum come stringa in C

Potenzia la metaprogrammazione del preprocessore

Di tanto in tanto uso le macro in modo da poter definire le informazioni in un unico posto, ma le uso in modi diversi in diverse parti del codice. È solo leggermente malvagio :)

Ad esempio, in "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

Quindi per un enum pubblico può essere definito semplicemente il nome:

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

typedef field_ {

#include "field_list.h"

    FIELD_MAX

} field_en;

E in una funzione init privata, tutti i campi possono essere usati per popolare una tabella con i dati:

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

#include "field_list.h"

Un uso comune è per rilevare l'ambiente di compilazione, per lo sviluppo multipiattaforma puoi scrivere un set di codice per Linux, diciamo, e un altro per Windows quando non esiste già una libreria multipiattaforma per i tuoi scopi.

Quindi, in un esempio approssimativo, può avere un mutex multipiattaforma

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

Per le funzioni, sono utili quando si desidera ignorare esplicitamente la sicurezza dei tipi. Come i molti esempi sopra e sotto per fare ASSERT. Naturalmente, come molte funzionalità C / C ++, puoi spararti ai piedi, ma la lingua ti dà gli strumenti e ti consente di decidere cosa fare.

Qualcosa di simile a

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

In modo che tu possa avere solo per esempio

assert(n == true);

e ottenere il nome del file di origine e il numero di riga del problema stampato nel registro se n è falso.

Se si utilizza una normale chiamata di funzione come

void assert(bool val);

invece della macro, tutto ciò che puoi ottenere è il numero di riga della tua funzione di asserzione stampato nel registro, il che sarebbe meno utile.

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

A differenza della soluzione modello 'preferita' discussa in un thread corrente, puoi usarla come espressione costante:

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

È possibile utilizzare #define per semplificare il debug e gli scenari di unit test. Ad esempio, creare varianti di registrazione speciali delle funzioni di memoria e creare uno speciale memlog_preinclude.h:

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

Compila il tuo codice usando:

gcc -Imemlog_preinclude.h ...

Un link nel tuo memlog.o all'immagine finale. Ora controlli malloc, ecc., Forse per scopi di registrazione, o per simulare errori di allocazione per unit test.

Quando si prende una decisione al momento della compilazione sul comportamento specifico del compilatore / OS / Hardware.

Ti permette di rendere la tua interfaccia alle funzioni specifiche di 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

Uso le macro per definire facilmente le eccezioni:

DEF_EXCEPTION(RessourceNotFound, "Ressource not found")

dove DEF_EXCEPTION è

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

I compilatori possono rifiutare la tua richiesta di inline.

Le macro avranno sempre il loro posto.

Qualcosa che trovo utile è #define DEBUG per la traccia di debug: puoi lasciarlo 1 durante il debug di un problema (o addirittura lasciarlo attivo durante l'intero ciclo di sviluppo), quindi spegnerlo quando è il momento della spedizione.

Nel mio ultimo lavoro, stavo lavorando su uno scanner antivirus. Per semplificare il debug delle cose, ho avuto molte registrazioni bloccate ovunque, ma in un'app molto richiesta come quella, le spese di una chiamata di funzione sono semplicemente troppo costose. Quindi, mi è venuta in mente questa piccola macro, che mi ha ancora permesso di abilitare la registrazione di debug su una versione di rilascio in un sito di clienti, senza il costo di una chiamata di funzione controllerebbe il flag di debug e ritornerebbe senza registrare nulla, o se abilitato , farebbe la registrazione ... La macro è stata definita come segue:

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

A causa del VA_ARGS nelle funzioni di registro, questo è stato un buon caso per una macro come questa.

Prima di allora, ho usato una macro in un'applicazione ad alta sicurezza che doveva dire all'utente che non avevano l'accesso corretto e che avrebbe detto loro di quale bandiera avevano bisogno.

Le macro definite come:

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

Quindi, potremmo semplicemente cospargere i controlli in tutta l'interfaccia utente e ti dirà quali ruoli sono stati autorizzati a svolgere l'azione che hai provato a fare, se non avessi già quel ruolo. La ragione per due di loro era di restituire un valore in alcuni punti e di ritornare da una funzione nulla in altri ...

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;
   }
...

Ad ogni modo, è così che li ho usati, e non sono sicuro di come questo avrebbe potuto essere aiutato con i template ... A parte questo, cerco di evitarli, a meno che REALMENTE necessario.

Ancora un altro foreach macro. T: tipo, c: contenitore, i: iteratore

#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 (concetto che mostra, non reale):

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;
}

Migliori implementazioni disponibili: Google "BOOST_FOREACH"

Buoni articoli disponibili: Amore condizionale: FOREACH Redux (Eric Niebler) http://www.artima.com/cppsource/foreach.html

Forse il grande uso delle macro è nello sviluppo indipendente dalla piattaforma. Pensa ai casi di incoerenza dei tipi - con le macro, puoi semplicemente utilizzare diversi file di intestazione - come: --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

Molto leggibile che implementarlo in altri modi, secondo me.

Sembra che VA_ARGS sia stato menzionato solo indirettamente finora:

Quando si scrive un codice C ++ 03 generico e è necessario un numero variabile di parametri (generici), è possibile utilizzare una macro anziché un modello.

#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: in generale, il controllo / lancio del nome potrebbe anche essere incorporato nell'ipoteticoget_op_from_name funzione . Questo è solo un esempio. Potrebbe esserci un altro codice generico che circonda la chiamata VA_ARGS.}

Una volta ottenuti i modelli variadic con C ++ 11, possiamo risolverlo "correttamente" con un modello.

Penso che questo trucco sia un uso intelligente del preprocessore che non può essere emulato con una funzione:

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

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

Quindi puoi usarlo in questo modo:

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

Puoi anche definire una macro RELEASE_ONLY.

È possibile #definecostanti nella riga di comando del compilatore utilizzando l' opzione -Do /D. Ciò è spesso utile durante la compilazione incrociata dello stesso software per più piattaforme poiché è possibile fare in modo che i propri makefile controllino le costanti definite per ciascuna piattaforma.