Quand les macros C ++ sont-elles utiles? [fermé]

Le préprocesseur C est à juste titre craint et rejeté par la communauté C ++. Les fonctions intégrées, les consts et les modèles sont généralement une alternative plus sûre et supérieure à un #define.

La macro suivante:

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

n'est en aucun cas supérieur au type safe:

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

Mais les macros ont leur place, veuillez lister les utilisations que vous trouvez des macros que vous ne pouvez pas faire sans le préprocesseur.

Veuillez mettre chaque cas d'utilisation dans une réponse distincte afin qu'il puisse être voté et si vous savez comment obtenir l'une des réponses sans le préprosesseur, indiquez comment dans les commentaires de cette réponse.

Encapsulent les fonctions de débogage, de passer automatiquement des choses comme __FILE__, __LINE__, etc:

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

Les méthodes doivent toujours être du code complet et compilable; les macros peuvent être des fragments de code. Ainsi, vous pouvez définir une macro foreach:

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

Et utilisez-le comme ceci:

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

Depuis C ++ 11, ceci est remplacé par la boucle for basée sur la plage .

Les gardes de fichiers d'en-tête nécessitent des macros.

Y a-t-il d'autres domaines qui nécessitent des macros? Pas beaucoup (le cas échéant).

Y a-t-il d'autres situations qui bénéficient des macros? OUI!!!

Un endroit où j'utilise des macros est avec du code très répétitif. Par exemple, lors de l'encapsulation de code C ++ à utiliser avec d'autres interfaces (.NET, COM, Python, etc ...), je dois attraper différents types d'exceptions. Voici comment je fais ça:

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

Je dois mettre ces captures dans chaque fonction de wrapper. Plutôt que de taper les blocs de capture complets à chaque fois, je tape simplement:

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

Cela facilite également la maintenance. Si jamais je dois ajouter un nouveau type d'exception, je n'ai besoin que d'un seul endroit pour l'ajouter.

Il existe également d'autres exemples utiles: dont beaucoup incluent les macros de préprocesseur __FILE__et __LINE__.

Quoi qu'il en soit, les macros sont très utiles lorsqu'elles sont utilisées correctement. Les macros ne sont pas mauvaises - leur mauvaise utilisation est mauvaise.

La plupart:

1. Inclure les gardes
2. Compilation conditionnelle
3. Rapports (macros prédéfinies comme __LINE__et __FILE__)
4. (rarement) Duplication de modèles de code répétitifs.
5. Dans le code de votre concurrent.

Dans la compilation conditionnelle, pour surmonter les problèmes de différences entre les compilateurs:

#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

Lorsque vous souhaitez créer une chaîne à partir d'une expression, le meilleur exemple est assert( #xtransforme la valeur de xen chaîne).

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

Les constantes de chaîne sont parfois mieux définies en tant que macros, car vous pouvez faire plus avec des littéraux de chaîne qu'avec un const char *.

Par exemple, les chaînes littérales peuvent être facilement concaténées .

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

Si a const char *était utilisé, une sorte de classe de chaîne devrait être utilisée pour effectuer la concaténation lors de l'exécution:

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

Lorsque vous souhaitez modifier le flux de programme ( return, breaket continue) le code dans une fonction se comporte différemment du code qui est en fait incorporé dans la fonction.

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

Les évidents incluent les gardes

#ifndef MYHEADER_H
#define MYHEADER_H

...

#endif

Vous ne pouvez pas effectuer de court-circuit des arguments d'appel de fonction à l'aide d'un appel de fonction normal. Par exemple:

#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

Disons que nous ignorerons les choses évidentes comme les gardes d'en-tête.

Parfois, vous souhaitez générer du code qui doit être copié / collé par le précompilateur:

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

ce qui vous permet de coder ceci:

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

Et peut générer des messages comme:

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

Notez que mélanger des modèles avec des macros peut conduire à des résultats encore meilleurs (c'est-à-dire générer automatiquement les valeurs côte à côte avec leurs noms de variables)

D'autres fois, vous avez besoin du __FILE__ et / ou du __LINE__ d'un code, pour générer des informations de débogage, par exemple. Ce qui suit est un classique pour Visual C ++:

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

Comme avec le code suivant:

#pragma message(WRNG "Hello World")

il génère des messages comme:

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

D'autres fois, vous devez générer du code en utilisant les opérateurs de concaténation # et ##, comme générer des getters et des setters pour une propriété (c'est pour un cas assez limité, à travers).

D'autres fois, vous générerez du code qui ne sera pas compilé s'il est utilisé via une fonction, comme:

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

Qui peut être utilisé comme

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

(encore, je n'ai vu ce genre de code correctement utilisé qu'une seule fois )

Dernier point, mais non le moindre, le fameux 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;
}

(Remarque: code copié / collé à partir de la page d'accueil Boost)

Ce qui est (à mon humble avis) bien meilleur que std::for_each.

Ainsi, les macros sont toujours utiles car elles sont en dehors des règles normales du compilateur. Mais je trouve que la plupart du temps j'en vois un, ce sont en fait des restes de code C jamais traduit en C ++ approprié.

Les frameworks de test unitaire pour C ++ comme UnitTest ++ tournent à peu près autour de macros de préprocesseur. Quelques lignes de code de test unitaire se développent dans une hiérarchie de classes qu'il ne serait pas du tout amusant de taper manuellement. Sans quelque chose comme UnitTest ++ et c'est la magie du préprocesseur, je ne sais pas comment vous pourriez écrire efficacement des tests unitaires pour C ++.

Craindre le préprocesseur C, c'est comme craindre les ampoules à incandescence simplement parce que nous obtenons des ampoules fluorescentes. Oui, le premier peut être {électricité | temps du programmeur} inefficace. Oui, vous pouvez être (littéralement) brûlé par eux. Mais ils peuvent faire le travail si vous le gérez correctement.

Lorsque vous programmez des systèmes embarqués, C est la seule option en dehors de l'assembleur de formulaires. Après avoir programmé sur le bureau avec C ++, puis basculé vers des cibles intégrées plus petites, vous apprenez à cesser de vous soucier des «inélégances» de tant de fonctionnalités C nues (macros incluses) et d'essayer simplement de déterminer la meilleure utilisation sûre que vous pouvez en tirer. fonctionnalités.

Alexander Stepanov dit :

Lorsque nous programmons en C ++, nous ne devons pas avoir honte de son héritage C, mais en tirer pleinement parti. Les seuls problèmes avec C ++, et même les seuls problèmes avec C, surviennent lorsqu'ils ne sont pas eux-mêmes cohérents avec leur propre logique.

Nous utilisons les macros __FILE__et __LINE__à des fins de diagnostic dans le lancement, la capture et la journalisation d'exceptions riches en informations, ainsi que des analyseurs de fichiers journaux automatisés dans notre infrastructure d'assurance qualité.

Par exemple, une macro de lancement OUR_OWN_THROWpeut être utilisée avec un type d'exception et des paramètres de constructeur pour cette exception, y compris une description textuelle. Comme ça:

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

Cette macro lancera bien sûr l' InvalidOperationExceptionexception avec la description comme paramètre du constructeur, mais elle écrira également un message dans un fichier journal composé du nom du fichier et du numéro de ligne où le lancer s'est produit et de sa description textuelle. L'exception levée obtiendra un identifiant, qui sera également enregistré. Si l'exception est déjà interceptée ailleurs dans le code, elle sera marquée comme telle et le fichier journal indiquera alors que cette exception spécifique a été gérée et qu'il est donc peu probable que ce soit la cause d'un crash qui pourrait être connecté plus tard. Les exceptions non gérées peuvent être facilement détectées par notre infrastructure QA automatisée.

Répétition du code.

Jetez un oeil pour booster la bibliothèque de préprocesseurs , c'est une sorte de méta-méta-programmation. Dans topic-> motivation, vous pouvez trouver un bon exemple.

Certains éléments très avancés et utiles peuvent encore être construits en utilisant un préprocesseur (macros), ce que vous ne pourriez jamais faire en utilisant les "constructions de langage" c ++, y compris les modèles.

Exemples:

Faire quelque chose à la fois d'un identifiant C et d'une chaîne

Un moyen facile d'utiliser des variables de types enum sous forme de chaîne en C

Booster la métaprogrammation du préprocesseur

J'utilise occasionnellement des macros pour pouvoir définir des informations en un seul endroit, mais je les utilise de différentes manières dans différentes parties du code. Ce n'est que légèrement mauvais :)

Par exemple, dans "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

Ensuite, pour une énumération publique, il peut être défini pour utiliser simplement le nom:

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

typedef field_ {

#include "field_list.h"

    FIELD_MAX

} field_en;

Et dans une fonction d'initialisation privée, tous les champs peuvent être utilisés pour remplir une table avec les données:

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

#include "field_list.h"

Une utilisation courante consiste à détecter l'environnement de compilation.Pour le développement multiplateforme, vous pouvez écrire un ensemble de code pour Linux, par exemple, et un autre pour Windows lorsqu'aucune bibliothèque multiplateforme n'existe déjà pour vos besoins.

Ainsi, dans un exemple approximatif, un mutex multiplateforme peut avoir

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

Pour les fonctions, elles sont utiles lorsque vous souhaitez ignorer explicitement la sécurité de type. Tels que les nombreux exemples ci-dessus et ci-dessous pour faire ASSERT. Bien sûr, comme beaucoup de fonctionnalités C / C ++, vous pouvez vous tirer une balle dans le pied, mais le langage vous donne les outils et vous permet de décider quoi faire.

Quelque chose comme

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

Pour que vous puissiez par exemple avoir

assert(n == true);

et obtenez le nom du fichier source et le numéro de ligne du problème dans votre journal si n est faux.

Si vous utilisez un appel de fonction normal tel que

void assert(bool val);

au lieu de la macro, tout ce que vous pouvez obtenir est le numéro de ligne de votre fonction d'assertion imprimé dans le journal, ce qui serait moins utile.

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

Contrairement à la solution de modèle `` préférée '' présentée dans un thread actuel, vous pouvez l'utiliser comme expression constante:

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

Vous pouvez utiliser #defines pour vous aider avec le débogage et les scénarios de test unitaire. Par exemple, créez des variantes de journalisation spéciales des fonctions de mémoire et créez un memlog_preinclude.h spécial:

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

Compilez votre code en utilisant:

gcc -Imemlog_preinclude.h ...

Un lien dans votre memlog.o vers l'image finale. Vous contrôlez maintenant malloc, etc., peut-être à des fins de journalisation, ou pour simuler des échecs d'allocation pour les tests unitaires.

Lorsque vous prenez une décision au moment de la compilation sur le comportement spécifique au compilateur / OS / matériel.

Il vous permet de créer votre interface avec des fonctionnalités spécifiques à 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

J'utilise des macros pour définir facilement les exceptions:

DEF_EXCEPTION(RessourceNotFound, "Ressource not found")

où DEF_EXCEPTION est

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

Les compilateurs peuvent refuser votre demande de mise en ligne.

Les macros auront toujours leur place.

Quelque chose que je trouve utile est #define DEBUG pour le traçage de débogage - vous pouvez le laisser 1 pendant le débogage d'un problème (ou même le laisser allumé pendant tout le cycle de développement), puis le désactiver quand il est temps d'expédier.

Dans mon dernier emploi, je travaillais sur un antivirus. Pour me faciliter le débogage, j'avais beaucoup de journalisation bloquée partout, mais dans une application à forte demande comme celle-ci, les frais d'un appel de fonction sont tout simplement trop chers. Donc, j'ai créé cette petite macro, qui m'a quand même permis d'activer la journalisation du débogage sur une version commerciale sur un site client, sans le coût d'un appel de fonction, vérifierait l'indicateur de débogage et retournerait sans rien enregistrer, ou si activé , ferait la journalisation ... La macro a été définie comme suit:

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

En raison de VA_ARGS dans les fonctions de journal, c'était un bon cas pour une macro comme celle-ci.

Avant cela, j'utilisais une macro dans une application de haute sécurité qui devait dire à l'utilisateur qu'il n'avait pas le bon accès, et cela lui disait de quel drapeau il avait besoin.

La ou les macro (s) définies comme:

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

Ensuite, nous pourrions simplement saupoudrer les vérifications sur toute l'interface utilisateur, et cela vous indiquerait quels rôles étaient autorisés à effectuer l'action que vous avez essayé de faire, si vous ne possédiez pas déjà ce rôle. La raison pour deux d'entre eux était de renvoyer une valeur à certains endroits, et de revenir d'une fonction vide à d'autres ...

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

Quoi qu'il en soit, c'est comme ça que je les ai utilisés, et je ne sais pas comment cela aurait pu être aidé avec des modèles ... A part ça, j'essaye de les éviter, à moins que VRAIMENT nécessaire.

Encore une autre macros foreach. T: type, c: conteneur, i: itérateur

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

Utilisation (concept montrant, pas réel):

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

Meilleures mises en œuvre disponibles: Google "BOOST_FOREACH"

Bons articles disponibles: Amour conditionnel: FOREACH Redux (Eric Niebler) http://www.artima.com/cppsource/foreach.html

Peut-être que la meilleure utilisation des macros est dans le développement indépendant de la plate-forme. Pensez aux cas d'incohérence de type - avec les macros, vous pouvez simplement utiliser différents fichiers d'en-tête - comme: --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

Beaucoup plus lisible que de l'implémenter autrement, à mon avis.

Il semble que VA_ARGS n'a été mentionné qu'indirectement jusqu'à présent:

Lorsque vous écrivez du code C ++ 03 générique et que vous avez besoin d'un nombre variable de paramètres (génériques), vous pouvez utiliser une macro au lieu d'un modèle.

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

_{Remarque: En général, le nom check / throw pourrait également être incorporé dans la get_op_from_namefonction hypothétique . C'est juste un exemple. Il peut y avoir un autre code générique entourant l'appel VA_ARGS.}

Une fois que nous obtenons des modèles variadiques avec C ++ 11, nous pouvons résoudre cela "correctement" avec un modèle.

Je pense que cette astuce est une utilisation intelligente du préprocesseur qui ne peut pas être émulée avec une fonction:

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

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

Ensuite, vous pouvez l'utiliser comme ceci:

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

Vous pouvez également définir une macro RELEASE_ONLY.

Vous pouvez #defineutiliser les constantes sur la ligne de commande du compilateur à l'aide de l' option -Dou /D. Ceci est souvent utile lors de la compilation croisée du même logiciel pour plusieurs plates-formes, car vous pouvez demander à vos makefiles de contrôler les constantes définies pour chaque plate-forme.