C et C++ mythe et realité

Ce n'est pas non plus la méta-programmation qui va faire ça, c'est la partie optimiseur du compilateur.

Citation:

---

Envoyé par Miles

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.

---

Oui et non. Par exemple tu fait un algorithm de traitement d'image spécifique pour un projet. Au lieu de réécritures comme une brut tout le code correspodant, tu va utiliser ces concepts, et ne pas repartir de zero. La metaprog est bonne que s'il y as les grande ligne connu à la compilation.

C'est le même problème que la STL, si tu veut.

Citation:

---

Envoyé par Miles

Ce n'est pas non plus la méta-programmation qui va faire ça, c'est la partie optimiseur du compilateur.

---

Ell va permetre de donner au compilot un code correspondant a ce que tu veut faire a un endroit de ton programme. Et en particulier sous une forme simple.
Ce qui correspont bien a une utilisation pour le traitement d'image.

Par exemple à un endroit du programme, tu veut passer un filtre sur une partie de l'image. Tu peut utiliser la metaprog pour te generer le code pour le parcoure de la partie de l'image et du noyau de calcul du filtre.

Tout de même, la STL est bien plus facilement utilisable que la méta-programmation. Par exemple les ouvrages dédiés à cette méthode montrent clairement que ce n'est déjà pas accessible à tout le monde (jamais des chercheurs en TS feront l'effort de l'utiliser, c'est complexe à programmer et à débugger) et ça ne fait pas tant de choses que ça.
En fait, je ne suis pas sûr qu'on parle exactement des mêmes outils. Par exemple, Boost propose une bibliothèque là-dessus, on va dire qu'à part travailler sur des types et des entiers, on ne peut pas faire grand chose d'autre.

J'imagine que par filtre, tu entends noyau de convolution dans l'exemple que tu as donnés.

De toute façon, le temps de création du filtre est en général totalement négligeable par rapport au temps pour l'appliquer (d'autant plus si le noyau est gros). Donc, je ne vois pas l'interêt si ça amène une complexité importante au niveau du code :roll:

Citation:

---

Envoyé par millie

J'imagine que par filtre, tu entends noyau de convolution dans l'exemple que tu as donnés.

De toute façon, le temps de création du filtre est en général totalement négligeable par rapport au temps pour l'appliquer (d'autant plus si le noyau est gros). Donc, je ne vois pas l'interêt si ça amène une complexité importante au niveau du code :roll:

---

justement çela va la simplifier
imagine une template

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

template< class _Tpixel, class _TPixelIterator, int _Hsize, int _Wsize, int _a1 =0, int _a2 =0, int _a3 =0, int _a4 =0, . . . int _an =0> class filter { . . . }

---

Plustôt que de re developper un code pour un filtre special, en prenant en compte tu ce que tu as besoin pour avoir accés au pixel voisin


ton filtre devient :
filter<RGB,2DIterator,3,3,-1 ,0,1,-1,0,1,-1,0,1> et tu n'aura pas écrit qu'une ligne de code


Ce n'est qu'un exemple simple bien sur

Citation:

---

Envoyé par Miles

Tout de même, la STL est bien plus facilement utilisable que la méta-programmation. Par exemple les ouvrages dédiés à cette méthode montrent clairement que ce n'est déjà pas accessible à tout le monde (jamais des chercheurs en TS feront l'effort de l'utiliser, c'est complexe à programmer et à débugger) et ça ne fait pas tant de choses que ça.
En fait, je ne suis pas sûr qu'on parle exactement des mêmes outils. Par exemple, Boost propose une bibliothèque là-dessus, on va dire qu'à part travailler sur des types et des entiers, on ne peut pas faire grand chose d'autre.

---

Tu peut voir la STL comme de la metaprog

La STL n'utilise que des notions basiques de métaprogr : les traits, principalement.

Je te conseille le bouquin "C++ Template Metaprogramming" avant de continuer à argumenter dans le vide.

Citation:

---

Envoyé par Mongaulois

justement çela va la simplifier
imagine une template

Ton filtre devient :
filter<RGB,2DIterator,3,3,-1 ,0,1,-1,0,1,-1,0,1> et tu n'aura pas écrit qu'une ligne de code


Ce n'est qu'un exemple simple bien sur

---

Oui, et ce n'est que de l'utilisation classique d'un template, pas vraiment de la méta-programmation comme je l'entend.
Il m'arrive d'utiliser des outils pour activer ou désactiver des fonctions selon le type utilisé, et je ne considère pas cela comme de la méta-programmation.
On commence vraiment à rentrer dans la méta-programmation en automatisant des tâches telles que des hiérarchies, des expressions ou du dispatching, mais sérieusement, 99% des gens ne devraient même pas savoir que ça existe tellement c'est complexe à mettre en oeuvre, à utiliser et à débugger.

La vraie métaprogrammation est très rare.
Les gens utilisant bien les templates un peu moins.

Les bonnes docs et bons livres que tu peux lire sur le sujet seront la doc de Boost.MPL, le bouquin que j'ai cité plus haut, des bouquins et articles de Andrei Alexandrescu.

Tu prendras alors conscience 1) de la portée de la métaprogrammation et de sa difficulté 2) des moments où l'on parle de métaprogr ainsi que ceux où l'on doit s'en servir.

Citation:

---

Envoyé par Alp

La STL n'utilise que des notions basiques de métaprogr : les traits, principalement.

Je te conseille le bouquin "C++ Template Metaprogramming" avant de continuer à argumenter dans le vide.

---

J'argumente pas dans le vide et en plus tu confirme ce que je dit. J'ai pas dit que c'était de la metaprog pur.
Toute façon c'est pas possible d'expliquer tout les concepts pour de la metaprog pour du traitement d'image en quelques lignes.
Faudrait que j'explique l'ensemble, ce qui deviens énorme. J'essaie de faire comprendre où ce trouve l'interêt. Aprés on n'est pas obligé d'être d'accord. Et c'est vrai que je n'ai pas d'exemple concret a vous donné :cry: (lib propriétaire)

Puis le but de ce post n'est pas de partir en troll. On peut faire un autre post sur çela si vous voulais.

On peut ouvrir un autre sujet, mais sincèrement, la seule fois que j'ai vu quelque chose qui ressemblait à de la métaprog en traitement d'image, c'était une utilisation classique des templates appliquée au conteneur qu'on utilisait (cf Vigra).

Citation:

---

Envoyé par Mongaulois

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

template< class _Tpixel, class _TPixelIterator, int _Hsize, int _Wsize, int _a1 =0, int _a2 =0, int _a3 =0, int _a4 =0, . . . int _an =0> class filter { . . . }

---

---

Comment on fait pour des noyaux de convolution de taille quelconque ?
Et il faut faire attention aussi si le noyau n'est pas carré.

Faire comme ça me semble plus simple conceptuellement http://subversion.developpez.com/pro...nel/Kernel.hpp
Ou (lien temporaire) : http://humbert-florent.developpez.co..._1_kernel.html

On pourra bientôt avec les variadic templates ;)

Citation:

---

Envoyé par Alp

On pourra bientôt avec les variadic templates ;)

---

yep :king:

En tout cas un grand merci à tous le monde pour toute ces réponses pertinente :king: . C'est super l'intéressante, et je comprend mieux un peu tout ce chmiblik

Sinon, pour revenir au sujet. Es que vous pourriez m'aider à lister la ou le C et le c++ ont leurs points forts et les sépare...

c++ :
- POO simplifié
- template
- metaprog
- flux
- programmation de haut niveau

C :
- POO compliqué mais puissante (ex GLIB,GTS)
- tous peut être (void*)
- flux
- programmation itératif (??)

Les avantages que tu donnes au C sont aussi pour le C++, même si on peut dire que l'avantage que tout puisse être void* est surtout la preuve d'un problème de conception en C++

Citation:

---

Envoyé par Miles

Les avantages que tu donnes au C sont aussi pour le C++, même si on peut dire que l'avantage que tout puisse être void* est surtout la preuve d'un problème de conception en C++

---

:cry: mais je dit pas ça (j'ai pas parlé de void* avec le c++) je cherche à trouver les vrais différences (conceptuel ou autre). Je programme en C++. Mais si je ne donne pas d'exemple, qui va m'aider? Je cherche à différencier correctement ces deux languages.
Aprés je peut écrire des erreur en C, puisse que j'ai compris que n'en faisait pas :D.
Sinon on n'as qu'as dire que C++ est du C avec plus de fonctionnalité et ça résous mon problème. Mais c'est faux. Aprés çela ne tiens peut être qu'a moi de vouloir comprendre ça. SI on n'est pas capable de les différencier, on ne pas affirmer qu'ils sont différents :?

Il y a quelques temps, le C++ était vraiment une surcouche du C car il respectait la norme C90. Maintenant, C99 est sorti, et donc il y a des nouveautés que le C++ n'a pas forcément et que le C a.
http://nicolasj.developpez.com/articles/c99/ donne ces nouveautés

Citation:

---

Envoyé par Miles

Il y a quelques temps, le C++ était vraiment une surcouche du C car il respectait la norme C90.

---

Il a de tout temps existé des programmes C valides qui n'étaient pas valides en C++. Par exemple un truc genre :

Code:

---

1 2 3 4 5 6 7 8 9

void f(void) { int i = g(); }   int g(void) { return 42; }

---

Le c99 ne demande t il pas aussi de déclarer les variables en début de portée?

Si si il me semble.

Citation:

---

Envoyé par MatRem

Le c99 ne demande t il pas aussi de déclarer les variables en début de portée?

---

Non, c'est justement une avancée du C99

JolyLoic > C'est du C valide, mais pas du C++ valide ? C'est dû à quoi ?

En C++ il faut prédéclarer l'existence des types/structures/classes/fonctions/... avant de s'en servir dans une autre entité.

Le C impose une sorte de "rétro-parsing" ?

Citation:

---

Envoyé par Miles

Il y a quelques temps, le C++ était vraiment une surcouche du C car il respectait la norme C90. Maintenant, C99 est sorti, et donc il y a des nouveautés que le C++ n'a pas forcément et que le C a.
http://nicolasj.developpez.com/articles/c99/ donne ces nouveautés

---

Merci pour le lien. Je connaissait pas les Variable-Length Arrays. Y as bien une autre philosophie en C

Citation:

---

Envoyé par JolyLoic

Il a de tout temps existé des programmes C valides qui n'étaient pas valides en C++. Par exemple un truc genre :

Code:

---

1 2 3 4 5 6 7 8 9

void f(void) { int i = g(); }   int g(void) { return 42; }

---

---

Beaucoup plus courant, la conversion implicite de void * en n'importe quel pointeur.

Citation:

---

Envoyé par Alp

Le C impose une sorte de "rétro-parsing" ?

---

Les fonctions -- sous certaines conditions de prototypes -- peuvent ne pas etre declaree avant d'etre utilisees.

Ok. Le compilo gère ça comment ? Il enregistre tous les appels à des fonctions non déclarées et voit si elles sont déclarées dans le même fichier plus bas ( ou dans un fichier inclus plus bas, ce qui au final revient presque au même )

Ah oui, effectivement, il y a un warning avec gcc qui est affiché en disant qu'il considère la fonction comme un je-ne-sais-plus-quoi.

Citation:

---

Envoyé par Alp

Ok. Le compilo gère ça comment ? Il enregistre tous les appels à des fonctions non déclarées et voit si elles sont déclarées dans le même fichier plus bas ( ou dans un fichier inclus plus bas, ce qui au final revient presque au même )

---

Il la compile comme si elle avait ete declaree avec un prototype particulier (type de retour int, type des parametres, celui qui est donne par les regles de promotions appliquees dans le cas des fonctions variadiques).

Citation:

---

Envoyé par Miles

la seule fois que j'ai vu quelque chose qui ressemblait à de la métaprog en traitement d'image, c'était une utilisation classique des templates appliquée au conteneur qu'on utilisait (cf Vigra).

---

Regarde Adobe.GIL (qui devient boost.GIL), tu vas devrais (mieux) servi en templates appliqués à la manipulation d'images.

C'est très proche de Vigra comme programmation (lui-même plus développé par certains aspects), mais ce n'est pas la panacée tout de même. Y'a rien de démentiellement extraordinaire en terme de méta-programmation dedans à part des choses simples, enfin je trouve.

Personnellement je ne fais pas vraiment du c ni vraiment du c++. Je fais du generic, un mix des deux. Généralement mes projets sont des projets c++ avec compilo g++, mais il y a un tas de chose que j'utilise qui viennent du c car je les trouve plus simple à manipuler, par exemple les flux! surtout les écritures/lectures en fichiers. Mais en gros je fais principalement du code en c-style et j'utilise les composants du c++ qui m'arrangent, que ce soit pour faire du calcul numérique pour ma these, ou bien pour faire du dev sous windows avec wxwidgets.

Les flux (stream) sont du C++, à moins que tu ne parles des FILE* ?

C'est dommage que tu n'utilises pas tout ce qu'apporte le C++.

Ces deux langages sont vraiment différents, donc autant à programmer en C++, sers-toi de la puissance supplémentaire disponible.

oui, lorsque je compte écrire/lire dans un fichier j'utilise FILE*

Pourquoi te servir de FILE* alors que les streams du C++ le remplacent avantageusement ?

Qu'est-ce que tu préfères dans l'implémentation C ?

Citation:

---

Envoyé par reptils

oui, lorsque je compte écrire/lire dans un fichier j'utilise FILE*

---

Si tu trouves ça plus simple que les flux C++, c'est que tu n'as pas vraiment donné leur chance à ces derniers.

Citation:

---

Envoyé par Alp

C'est dommage que tu n'utilises pas tout ce qu'apporte le C++.

Ces deux langages sont vraiment différents, donc autant à programmer en C++, sers-toi de la puissance supplémentaire disponible.

---

peut etre qu'a terme je passerai de plus en plus au c++ style, mais pour le moment vu que je fais principalement du calcul numerique je n'ai AUCUN apport du c++ vis-avis du c. La seul raison pour laquelle mon code elements finis pour calculer mes champs electromagnetiques est faite en c++ c'est juste par rapport à l'existance de la class complex. Car meme si la norme C99 defini les nombres complex je trouve ça moins clair...
J'ai une questoin à propos du c++ sur l'allocation dynamique. si je fais:

Code:

---

MaClass* tab=new MaClass[nb_element]

---

tab est un tableau de type MaClass alloué à nb_element? et si oui, je ne vois pas à quel moment on fait appel au constructeur pour chaque element?

EDIT: pour cette histoire de stream, c'est juste que je trouve moins pratique pour formatter la sortie en c++. Genre si je veux mettre un entier de 7 places puis un reel écrit au format scientifique avec un certaine précision etc c'est plus simple avec printf je trouve.

Citation:

---

Envoyé par Laurent Gomila

Si tu trouves ça plus simple que les flux C++, c'est que tu n'as pas vraiment donné leur chance à ces derniers.

---

je sui d'accord avec reptils (pour le formatage des fichiers).
La seul reponse que j'ai eu pour faire la même chose est BOOST, il faut donc faut ajouter des fichier :cry:

Citation:

---

Envoyé par reptils

J'ai une questoin à propos du c++ sur l'allocation dynamique. si je fais:

Code:

---

MaClass* tab=new MaClass[nb_element]

---

tab est un tableau de type MaClass alloué à nb_element? et si oui, je ne vois pas à quel moment on fait appel au constructeur pour chaque element?

---

Oui et en même temp. Le new va alloué l'espace memoire necessaire pour tes instances et appeler le constructeur par default pour chaqu'une d'elle.