Discussion :

[koala01]

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

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

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

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

[Alp]

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.

[Matthieu Brucher]

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 !

[Alp]

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.

[Matthieu Brucher]

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

[Alp]

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

[JolyLoic]

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

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*).

[yan]

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.

[yan]

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

[Matthieu Brucher]

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)

[yan]

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)

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

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

[zais_ethael]

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

[Alp]

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

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

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.

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

[Jean-Marc.Bourguet]

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

unsigned char serait mieux.

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

[Matthieu Brucher]

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

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.

[zais_ethael]

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.

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?).

[Jean-Marc.Bourguet]

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.

[yan]

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

[Matthieu Brucher]

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.

[yan]

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

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.