Citation:
Envoyé par
Freem
Je ne trouve pas.
Parce que la ou je vois du préprocesseur, c'est pour:
_ activer/désactiver des options dans un logiciel. Chose qui pourrait être faite via un système de plugin, moyennant une architecture étudiée dans ce sens.
Sauf que parfois l'overhead peut être extrèmement couteux. (enfin, ça dépend si on parle de plugin à la compilation ou à l'exécution, mais j'ai plus tendance à appeler modules les plugins à la compilation)
Citation:
_ garantir la compatibilité entre divers OS. En fait, souvent garantir la compatibilité avec windows. Les #IFDEF que je vois sous souvent suivis de WIN32...
Toujours est-il que la compatibilité est toujours importante, quelle que soit l'opinion qu'on se fait du système ciblé et de ses API.
Citation:
L'utilisation des macros, quand à elle, est plutôt anecdotique. Par exemple, elles sont utilisées par wxWidgets pour gérer les évènements. Sauf qu'ils ont enfin laissé tomber ce système pour un basé sur des callbacks.
Je les utilise dans un projet professionnel également, pour écrire plus vite des classes de wrapper, qui n'ont strictement aucune logique dedans. Et d'ailleurs, elles sont trop limitées pour ce que je voudrais en faire. (J'aurai bien utilisé les variadic template, malheureusement, je dois utiliser VS2008...)
Quand je disais avant les variadic templates, je pensais entre autres a fait de proposer des fonctions variadic templates.
Exemple : boost.function pré-variadic templates.
Et, comme tu le dis si bien, les macros sont toujours nécessaires pour faire une partie le boulot sur un compilo sans les variadics, et ces compilateurs existent malheureusement encore ...
Alors, oui, il y a boost & co. pour nous cacher les macros, mais c'est un des trois langages du c++ (en excluant l'asm, hein -- je ne suis pas sûr que je n'en oublie pas d'autre), chacun influant sur son moment de la compilation / de l'exécution.
Citation:
Ah, si, une autre utilisation des macros, non remplaçable par les variadic templates: pouvoir écrire du code de journalisation, surtout pour le mode debug, grâce aux macros __LINE et __FILE. Très utile ça pour le débogage. Mais pas pour le code métier je pense.
M'est avis que le code métier a quand même des macros avec, désactivés avec l'activation de NDEBUG.
Citation:
Autre chose qui nécessite les directives de préproc, les header guard. Ajouter le fameux #ifndef TRUC_H #define TRUC_H #endif dans les header n'est cependant qu'un idiome auquel on ne fait plus attention au bout de 2 mois. (Je me demande d'ailleurs pourquoi les header ne sont pas traités comme ça par défaut mais bon...)
Parce que sinon beaucoup d'autres idiomes disparaitraient ?
Exemple, boost.pp.iterate_file (ou quelque chose du genre).