C et C++ mythe et realité

Le C et le C++ sont deux langages distincts qui partagent un large sous-ensemble. Celui-ci est fort proche du C, mais il n'empêche que quelqu'un connaissant les deux langages remarquera rapidement si quelque chose a été écrit en C++, en C ou dans le sous-ensemble commun.

En pratique, il est commun d'utiliser des bibliothèques écrites en C en C++. Mais c'est le cas dans d'autres langages aussi. Et les solutions sont alors les mêmes: soit on écrit une couche mince faisant la conversion, et le style de la bibliothèque initiale est toujours sensible quand on l'utilise, soit on écrit une couche plus épaisse, gardant le coeur de la fonctionalité mais fournissant une interface plus adaptée au langage utilisé. En C++, la première solution est particulièrement aisée, il suffit de faire un include a l'intérieur d'un bloc extern "C" (et parfois ce bloc n'est pas nécessaire car les auteurs de la bibliothèque C l'ont prévu). Mais ce n'est pas pour autant qu'elle est fondamentalement différente des langages ou la couche mince doit être écrite a la main ou générée par un programme auxiliaire.

Citation:

---

Envoyé par Laurent Gomila

L'utilisation de boost devient de plus en plus inévitable

---

d'ailleurs c'est bien simple, sauf erreur, il y a des pans entiers de boost qui vont entrer dans la nouvelle norme...

Citation:

---

Envoyé par Mongaulois

Ben dans visual 2005 si :cry: (c'etait un autre post). j'ai reussi a les viré avec les option de compilation, mais je trouve pas sa propre.

---

Mais d'un autre côté, on ne peut pas vraiment dire non plus que le respect des normes, quelles qu'elles soient, ait jamais été l'une des préoccupations majeures de microsoft... bon :dehors:

Citation:

---

Y as bien sur une limite a tout cela. C++ n'est qu'en patie du C. Mais dire qu'ils sont totalement différent et un peu trop rapide.

---

Ils sont totalement différents...

Ne serait-ce que parce que C++ "automatise" une série de choses qui sont de véritable PAC (Pièges à C:aie:) en C...

Et pour ce qui est "nouveau" en C++ l'utilisation est bien plus simple que les solutions à mettre en oeuvre pour arriver à un résultat similaire en C... et bien mieux sécurisé...

Je suis d'accord avec le fait que Strutroup (désolé si j'ai écorché son nom :oops:) justifie le nom C++ par le fait que

Citation:

---

Envoyé par strutroup(très apporximativement)

C++ est un C évolué ainsi que le montre le "++" (qui correspond à C=C+1) mais n'est pas un "nouveau" langage (qui aurait donné un D)

---

Mais le fait que ce soit une évolution (et je n'hésite pas à rajouter le mot "majeure" :D) du C fait... que ce n'est plus du C... C'est autre chose :D

Citation:

---

Je suis d'accord qu'il faut au maximum les séparer. Ce qui n'est pas toujours facile.

---

Si, c'est facile, accepte l'idée d'abandonner la CLib au profit des possibilités offertes par le C++ quand tu travaille en C++...

Citation:

---

Par exemple les struct peuvent être aligné en C++ et non en C(du moins il me semble) ce qui peut poser de grave problème d'interfacage entre du C et du C++...

---

Comme tout, cela peut poser problème si tu l'utilise à mauvais escient ou si tu pars sur de fausses hypothèses.

Mais si le programme en C ne part pas sur des hypothèses non vérifiées, finalement, que la structure soit alignée ou non ne posera aucun problème d'interfacage :D

Citation:

---

Envoyé par koala01

Citation:

---

Envoyé par mongaulois

Je suis d'accord qu'il faut au maximum les séparer. Ce qui n'est pas toujours facile.

---

Si, c'est facile, accepte l'idée d'abandonner la CLib au profit des possibilités offertes par le C++ quand tu travaille en C++...

---

Ha oui? Je te met au défi de me faire un pilote TWAIN en c++ (le premier qui me vient à l'esprit, mais il y a des centaines d'autres exemples) sans faire une ligne de C "pur" ;)

Citation:

---

Envoyé par Mongaulois

Par exemple les struct peuvent être aligné en C++ et non en C(du moins il me semble) ce qui peut poser de grave problème d'interfacage entre du C et du C++...

---

Moi, il me semble fortement qu'en C aussi, il y a possibilités de contraintes d'alignement sur des structures. Mais comme je ne connais pas le C, je ne peux rien affirmer.

Citation:

---

Envoyé par JolyLoic

Moi, il me semble fortement qu'en C aussi, il y a possibilités de contraintes d'alignement sur des structures.

---

Exact.

Citation:

---

Envoyé par r0d

Ha oui? Je te met au défi de me faire un pilote TWAIN en c++ (le premier qui me vient à l'esprit, mais il y a des centaines d'autres exemples) sans faire une ligne de C "pur" ;)

---

Comme je n'ai pas le prémisse du début de la moindre idée des besoins d'un pilote TWAIN, je crains fort de n'être vraiment pas en mesure de le relever :P

Ce qui ne veut absolument pas dire non plus que, quand bien même j'aurais des connaissances suffisantes sur le protocole, que j'y arriverais, il faut bien l'avouer :D

pour un peu d'histoire(passé et futur) resumé du C et C++ vous pouvez regarder
http://www.research.att.com/~bs/C++0x_keynote.pdf

Citation:

---

Envoyé par r0d

Ha oui? Je te met au défi de me faire un pilote TWAIN en c++ (le premier qui me vient à l'esprit, mais il y a des centaines d'autres exemples) sans faire une ligne de C "pur" ;)

---

Puf, finger in the noze 8-) euh non enfaite...
Du coup c'est un peu de C et un peu de c++ :cry:. Ou alors on peut dire que C++ peut émuler du C?

Citation:

---

Envoyé par r0d

Ha oui? Je te met au défi de me faire un pilote TWAIN en c++ (le premier qui me vient à l'esprit, mais il y a des centaines d'autres exemples) sans faire une ligne de C "pur" ;)

---

J'aimerais bien savoir ce que tu entends par du "C pur".

Citation:

---

Envoyé par Jean-Marc.Bourguet

Le C et le C++ sont deux langages distincts qui partagent un large sous-ensemble. Celui-ci est fort proche du C, mais il n'empêche que quelqu'un connaissant les deux langages remarquera rapidement si quelque chose a été écrit en C++, en C ou dans le sous-ensemble commun.

En pratique, il est commun d'utiliser des bibliothèques écrites en C en C++. Mais c'est le cas dans d'autres langages aussi. Et les solutions sont alors les mêmes: soit on écrit une couche mince faisant la conversion, et le style de la bibliothèque initiale est toujours sensible quand on l'utilise, soit on écrit une couche plus épaisse, gardant le coeur de la fonctionalité mais fournissant une interface plus adaptée au langage utilisé. En C++, la première solution est particulièrement aisée, il suffit de faire un include a l'intérieur d'un bloc extern "C" (et parfois ce bloc n'est pas nécessaire car les auteurs de la bibliothèque C l'ont prévu). Mais ce n'est pas pour autant qu'elle est fondamentalement différente des langages ou la couche mince doit être écrite a la main ou générée par un programme auxiliaire.

---

Je croit voir mon problème. C'est que je ne doit pas comprendre (et ne suis pas le seul) ce qu'es réellement le C... et je pense que je mélange ce sous ensemble est le C. Et c'est la ou est le problème...

Citation:

---

Envoyé par Jean-Marc.Bourguet

J'aimerais bien savoir ce que tu entends par du "C pur".

---

Par exemple, une fonction "libre" (par opposition à fonction membre) qui prend un char* en paramètre.
Peut-être que "C pur" n'est pas adéquat, j'ai toujours du mal avec la terminologie.

Citation:

---

Envoyé par r0d

Par exemple, une fonction "libre" (par opposition à fonction membre) qui prend un char* en paramètre.

---

Et pourquoi tu t'en priverais si c'est ce qu'il faut?

Citation:

---

Peut-être que "C pur" n'est pas adéquat, j'ai toujours du mal avec la terminologie.

---

En fait, je crois que je vois l'idee mais j'ai beaucoup de mal avec les limites. Et comme avec un exemple de "driver", tu es en train de jouer avec les limites, j'aimerais savoir ou tu les places.

Le C++ a ete concu comme langage pouvant manipuler des concepts de bas niveau. Les fonctionnalites necessaires, il les a principalement heritees du C. Si c'est ce que tu fais, tu vas naturellement programmer avec quelque chose qui est proche du sous-ensemble commun du C et du C++, mais si tu es en C++, tu vas peut-etre utiliser des choses comme les templates ou les references parce que ca conviendra mieux que des macros ou des pointeurs.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Et pourquoi tu t'en priverais si c'est ce qu'il faut?

---

C'est justement ce que j'étais en train de dire. Parfois, non seulement on ne peut pas s'en passer, mais en plus ça n'en vaut pas la peine (d'essayer de s'en passer).

Citation:

---

Envoyé par Jean-Marc.Bourguet

En fait, je crois que je vois l'idee mais j'ai beaucoup de mal avec les limites. Et comme avec un exemple de "driver", tu es en train de jouer avec les limites, j'aimerais savoir ou tu les places.

---

En fait, ce n'est pas le fait de développer un driver que je voulais mettre en exergue, mais le fait d'interfacer une lib écrite en C.

Citation:

---

Envoyé par r0d

En fait, ce n'est pas le fait de développer un driver que je voulais mettre en exergue, mais le fait d'interfacer une lib écrite en C.

---

Citation:

---

Envoyé par Jean-Marc Bourguet

En pratique, il est commun d'utiliser des bibliothèques écrites en C en C++. Mais c'est le cas dans d'autres langages aussi. Et les solutions sont alors les mêmes: soit on écrit une couche mince faisant la conversion, et le style de la bibliothèque initiale est toujours sensible quand on l'utilise, soit on écrit une couche plus épaisse, gardant le coeur de la fonctionalité mais fournissant une interface plus adaptée au langage utilisé. En C++, la première solution est particulièrement aisée, il suffit de faire un include a l'intérieur d'un bloc extern "C" (et parfois ce bloc n'est pas nécessaire car les auteurs de la bibliothèque C l'ont prévu). Mais ce n'est pas pour autant qu'elle est fondamentalement différente des langages ou la couche mince doit être écrite a la main ou générée par un programme auxiliaire.

---

Citation:

---

Envoyé par r0d

En fait, ce n'est pas le fait de développer un driver que je voulais mettre en exergue, mais le fait d'interfacer une lib écrite en C.

---

J'ai jeté un rapide coup d'oeil à twain.h (j'avoue avoir été ... découragé par le seul fait de me rendre compte que les spécifications prenaient plus de 500 pages...en anglais :P)

Mais, l'un dans l'autre, qu'est ce qui pourrait t'empêcher de créer des classes pour encapsuler les différentes structures déclarées, et d'en profiter, par exemple, pour redéfinir les opérateurs de flux :question:

A partir de là, en fournissant les fonctions "qui vont bien" pour respecter le protocole, tu pars sur un interfacage des plus facile, non :question:

Par contre, l'exemple d'une fonction prenant un char* (qu'elle soit libre ou non) est, malheureusement un contre exemple...

Finalement, si la signature attend une référence sur std::string constante, elle acceptera sans aucun problème qu'on lui fournisse un char* lors de l'appel :P:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include <string> #include <iostream> using namespace std; void Mafonct(const string& s) { cout<<s; } int main() { char str[15]; strcpy(str,"salut"); Mafonct(str);// c'est clairement un char* que je lui passe return 0; }

---

Mais char * fait bien partie du c++ (ce fameux sous ensemble qui se trouve aussi dans le c :P) .... non?

Citation:

---

Envoyé par MatRem

Mais char * fait bien partie du c++ (ce fameux sous ensemble qui se trouve aussi dans le c :P) .... non?

---

Voyons voir...

• le primitif char fait partie du sous ensemble
• La notion de pointeurs aussi

Donc, en toute logique, un pointeur sur char fait partie du sous-ensemble :D

Ceci dit, la gestion au jour le jour est largement plus simple sous la forme d'une std::string que sous la forme d'un pointeur de char :P

Oui tout à fait...

En fait c'est un contre exemple de quoi alors la fameuse fonction qui prend un char *?
... j'ai pas du saisir :aie:

Ben, c'est surtout qu'il te sera beaucoup plus facile, bien qu'un pointeur sur char fasse partie intégrante du C++, de préférer une fonction prenant une référence sur un std::string :D

En fait, je viens de me rendre compte qu'il y a peut être bien un problème de communication, qu'il vaut mieux lever :P

Je viens en effet de réaliser qu'un char* n'est, en définitive, pas forcément une chaîne de caractères... Enfin, je le savais, mais je ne l'avais pas pris en compte :oops:

Donc MatRem, je dirais que le contexte de ta fonction prenant un char* devrait être précisé:

Si tu en parle comme une fonction utilisant le char* comme une chaîne de caractères, mon avis (personnel) est que tu es clairement mieux de la déclarer comme prenant une référence sur une std::string constante, de gérer le tout sous la forme de std::string, et de ne passer en char* que si tu a vraiment besoin d'un tableau de caractères ou d'une chaîne "C style".

Si, par contre, tu parle de cette fonction dans le contexte d'une fonction prenant un pointeur sur "un tableau de valeurs comprises entre 0 et 255" (en s'entendant sur le fait qu'un char ne fait pas forcément 8 bits :P), dans le cadre, par exemple, de l'utilisation de certaines bibliothèques ou de certains protocoles, il est clair que l'utilisation d'une std::string n'est pas envisageable, vu que la chaîne sera considérée comme finie au premier caractère '\0' rencontré, et ce, même s'il devait encore y avoir 1Mb de données qui le suit:P

Mais, malgré tout, ce n'est pas parce qu'une fonction prendrait un char* que tu ne coderait plus en C++... étant donné que la "simple logique" nous indique que le pointeur sur char fait partie du sous ensemble commun :D

En fait, comme le C compose un sous-ensemble du C++, on ne peut distinguer que la partie "C++ non C" ou "C++ pur". Seulement, du moment où l'on définit main, on écrit du "C++ non pur" si l'on peut dire. Le C++ ayant beaucoup hérité du C, on ne peut pas s'en passer.

Cependant, pour revenir au sujet initial, délimiter C et C++ pour écrire du "C++ pur" n'est pas la bonne façon de penser.

Si on programme en C++, on écrit des templates, on utilise des références, on écrit des classes, etc ...
Cela entraine que l'on fait de la POO et/ou de la PG.

Mais se dire qu'il faut utiliser cela juste pour faire du C++ pur, c'est penser à l'envers.

Parfois, il est bon d'utiliser des fonctions libres (par opposition à fonction membre) pour contourner des difficultés.

Parfois, on a besoin d'écrire des foncteurs, auquel cas là on utilise le "C++ non C".

Il faut simplement savoir distinguer quand est-ce qu'on a besoin d'utiliser des notions C++-only et quand est-ce qu'il faut utiliser des choses héritées du C.

Comment faire cette distinction ? Cela viendra avec la pratique et après la lecture de documents, de FAQ et autres livres.

Citation:

---

Envoyé par Alp

Parfois, il est bon d'utiliser des fonctions libres (par opposition à fonction membre) pour contourner des difficultés.

---

C'est même indispensable si on ne veut pas finir avec une classe fourre-tout comme std::string !

Oui en effet. Parfois cela permet de rendre l'organisation plus facilement maintenable.

La preuve qu'on ne peut se passer du sous-ensemble C, lorsque l'on veut bien faire.

Une fonction libre n'est pas forcément du C. C'est tout de même une base aussi de la modularité et de la réutilisabilité.

Mais c'est un héritage du C (c'est pas du C-only, mais ça vient du C).

Citation:

---

Envoyé par koala01

il est clair que l'utilisation d'une std::string n'est pas envisageable, vu que la chaîne sera considérée comme finie au premier caractère '\0' rencontré, et ce, même s'il devait encore y avoir 1Mb de données qui le suit:P

---

Une std::string peut avoir des '\0' au milieu, et marcher quand même très bien, contrairement à la plupart des fonctions gèrant des char*, le '\0' n'a pas en général de signification particulière pour un std::string (il en a juste, par exemple, pour créer un string à partir d'un char*).

voila un passage d'un article de Bjarne Stroustrup "C++ Programming Styles and Libraries"

C++ is a multiparadigm programming language. That is, C++ supports several styles of programming:
- C-style programming : C++ is a better C, maintaining C’s flexibility and run-time efficiency while improving type checking;

- Data abstraction : the ability to create types that suit our needs;

- Object-oriented programming : the idea of programming with class hierarchies and runtime polymorphism;

- Generic programming programming : using type parameterization of both data types and algorithms.

Pour faire un petit résumé (dit moi c'est je me trompe)

C et C++ sont deux styles et concepts différents de programmation. Tout les deux ont un sous ensemble commune, ce qui permet au code C++ (je parle bien de "C++ et C" pas "C et C++) d'être plus souple et peut être performant :
- Il simplifie fortement les concepts objets
- Permet du faire des morceaux en "pseudo-C", pour des performances, interagir avec des lib C sans difficulté (enfin presque..)
- template (empêche la réécriture inutile de code)
- meta-prog (optimise le code généré)

après, il faut mieux, pour la rapidité, stabilité, évolution d'un code, d'utilisé ce qui existe déja (STL,Algorithm...) et d'utilisé Boost pour les manques actuels. Mais rien n'empêche de faire du pseudo-C pour optimisé des morceau de code et faire ses propre class, tans que l'on sait ce que l'on fait.

Donc je dirait qu'il faudrai déjà bien exploité les ressources du C++, avant d'aller plus loin et d'utiliser du pseudo-C.

Je pense qu'un vrai programmeur C peut en dire autant pour C :)

Le C++ n'a pas besoin du pseudo-C pour être performant

La méta-programmation est effectuée à l'aide des template, ce sont ces derniers principalement qui font la généricité et la possibilité d'avoir de meilleurs performances (la méta-prog permet de créer un programme dont certaines parties peuvent être calculées à la compilation, mais c'est rare)

Citation:

---

Envoyé par Miles

Le C++ n'a pas besoin du pseudo-C pour être performant

---

Ca depend du point de vu. Par exemple utiliser un vector comme buffer d'une image, les performance sous GCC et visual2005 ne sera pas la même (car l'operateur [] fait une verif avec visual 2005). Dont pour un code multi-plateforme et optimisé on va plustôt utilisé un tableau dynamic( ce que j'appel pseudo-C)

Citation:

---

Envoyé par Miles

La méta-programmation est effectuée à l'aide des template, ce sont ces derniers principalement qui font la généricité et la possibilité d'avoir de meilleurs performances (la méta-prog permet de créer un programme dont certaines parties peuvent être calculées à la compilation, mais c'est rare)

---

la méta-prog existe grâce au performance des compilateurs, sinon ce ne serait que des templates. C'est vrai que ca ne servira pas a tout le monde. Pour du traitement d'image ça peut servir:D

Sinon mon résumé est bon? ou trop simpliste? ou carrément a côté de la plaque?

J'aimerais ajouter un petit mot sur les char*.
En général, je met un point d'honneur à ne jamais les utiliser. Si je dois désigner une chaine de caractères, j'utilise un string. Si je dois désigner une suite de byte j'utilise un vector<char>. Ce n'est qu'au tout dernier moment où-que-j'ai-une-fonction-qui-me-demande-un-const-char* que je fais la convertion soit via un string.c_str() soit un &vector[0],vector.size(). Non seulement c'est du bon C++ bien encapsulé avec alloc dynamique et sans risque de fuite mémoire, mais ça me permet d'indiquer clairement ce qu'est ma variable sans avoir à me poser la question (j'ai toujours trouvé r.i.d.i.c.u.l.e que le C ne fasse aucune différenciation caractère<->byte).
Et pour ce qui est de l'opérateur [] sous visual, définir une directive de compilation dans le projet n'est pas cher payé, il faut de toutes façons faire bien plus que ça pour sortir une release (à commencer par la solution de déploiement).

Citation:

---

Envoyé par Mongaulois

Ca depend du point de vu. Par exemple utiliser un vector comme buffer d'une image, les performance sous GCC et visual2005 ne sera pas la même (car l'operateur [] fait une verif avec visual 2005). Dont pour un code multi-plateforme et optimisé on va plustôt utilisé un tableau dynamic( ce que j'appel pseudo-C)

---

Si ce n'est que ça, tu fais un #ifdef _MACRO_POUR_VISUAL_2005 pour changer le type du tableau juste pour vs2005 et voilà.

Citation:

---

Envoyé par Mongaulois

la méta-prog existe grâce au performance des compilateurs, sinon ce ne serait que des templates. C'est vrai que ca ne servira pas a tout le monde. Pour du traitement d'image ça peut servir:D

---

Ah non, les compilateurs suivent les specs, et inlinent parfois tout seul certaines choses. C'est la conception des templates, en grande partie, qui fait le boulot.

Citation:

---

Envoyé par Mongaulois

Sinon mon résumé est bon? ou trop simpliste? ou carrément a côté de la plaque?

---

C'est difficile à dire, tu fais les questions et les réponses :aie:

Citation:

---

Envoyé par zais_ethael

Si je dois désigner une suite de byte j'utilise un vector<char>.

---

unsigned char serait mieux.

Citation:

---

(j'ai toujours trouvé r.i.d.i.c.u.l.e que le C ne fasse aucune différenciation caractère<->byte).

---

Ne jamais oublie que C est un descendant de B et que B est un langage non type. Ca explique beaucoup.

Citation:

---

Envoyé par Mongaulois

la méta-prog existe grâce au performance des compilateurs, sinon ce ne serait que des templates. C'est vrai que ca ne servira pas a tout le monde. Pour du traitement d'image ça peut servir:D

---

Pour en faire régulièrement, je dirai que c'est sans doute un des endroits où c'est moins utilisable. Enfin, si tu as des exemples, je suis preneur.

Citation:

---

Envoyé par Jean-Marc.Bourguet

unsigned char serait mieux.

---

Comme la plupart des biblio utilisent char et se débrouillent toutes seules avec le bit de signe, ça dispense de faire un casting dans la majorité des cas.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Ne jamais oublie que C est un descendant de B et que B est un langage non type. Ca explique beaucoup.

---

On programme en C, pas en B. Certaines aberrations n'ayant jamais été corrigées pour des questions de rétro-compatibilité ne sont déja pas simples à digérer, on ne va pas accepter celles qui sont toujours présentes sans aucune raison (à ma connaissance, il n'y a aucune compatibilité entre le C et le B pas vrai?).

Citation:

---

Envoyé par zais_ethael

On programme en C, pas en B. Certaines aberrations n'ayant jamais été corrigées pour des questions de rétro-compatibilité ne sont déja pas simples à digérer, on ne va pas accepter celles qui sont toujours présentes sans aucune raison (à ma connaissance, il n'y a aucune compatibilité entre le C et le B pas vrai?).

---

Et il la compatibilite entre le C90 et celui utilise pour ecrire unix V6 est faible. Pourtant l'influence est la. Il y a toujours eu trop de code existant a casser pour le benefice previsible. Le C et le C++ ne sont pas des langages qui sont sortis casques de la tete de leurs concepteurs, ce sont des langages qui ont evolues pour repondre aux besoins percus. Ca leur donne des avantages -- ils sont bien adaptes a ce pour quoi ils ont ete concus -- et des inconveniants -- certaines choses ne s'expliquent que par l'histoire. Arriver maintenant et dire il y avait moyen de faire mieux, c'est possible, mais est-ce que les langages auraient alors survecus? C'est pas certain. Les concepteurs de l'epoque connaissaient beaucoup mieux que nous les contraintes de l'epoque.

Citation:

---

Envoyé par Miles

Pour en faire régulièrement, je dirai que c'est sans doute un des endroits où c'est moins utilisable. Enfin, si tu as des exemples, je suis preneur.

---

Par exemple si tu connait la taille de ton filtre avant la compilation, tu peut par metaprog générer ton noyau de calcul à appliquer sur une image.

Tu peut faire en sort de simplifier les écriture genre :
Ires= IA+IB*IC/2 comme ce que fait blitz++ ou même allez plus loin pour faire des EDP.

Utiliser de prédicat pour tes noyau de calcul...

Des méthodes de parcours de l'image.

Des conceptions de forme pour appliquer tes filtre ou autre transformation..
Ca peut allez trés loin. Tout cela tu peut le faire grace au template et a la meta-prog.

Problème est que le seul vrai exemple que je connaisse et propriétaire chez le client où je suis, et non distribué.... Mais Blitz++ et un bon exemple si tu considère l'image comme une matrice 2D

Sauf que dans la vie réelle, tu ne connais pas la taille de ton filtre, tu dois pouvoir fournir plusieurs parcours sur ton image, ...
C'est facile avec les templates, mais le seul intérêt à ce moment de la métaprogrammation est d'instancier automatiquement toutes les possibilités et de les enregistrer à un endroit pour y avoir accès de l'extérieur. C'est limité tout de même.

Citation:

---

Envoyé par Alp

Ah non, les compilateurs suivent les specs, et inlinent parfois tout seul certaines choses. C'est la conception des templates, en grande partie, qui fait le boulot.

---

Mais c'est le compilot qui interprete la meta prog :dehors:

Pour ce que je comprend de la meta prog, c'est une façon d'utiliser les templates pour faire de l'autogénération de code.

ce n'est pas les templates qui va optimiser au final le code, comme enlever des morceau de code qui ne sert a rien comme if(vrai), i=a*2+b*4+c*0.+d*0 remplacé par i=a*2+b*4; ou comme tu dit inliné les fonction qui ne serve a rien.